Sommaire

BONJOUR
Musique "Invention BWV784" J.S. BACH 1685-1750

Tutoriel et Help

Style & CSS


Accueil

Accueil CHM


Accueil

La page vide

Normal, dit comme ça,
vous ne risquez pas de comprendre.


Accueil

La page vide

J2M
J2M

JAVASCRIPT


Les feuilles de style en cascade, niveau 1

Recommandation du W3C du 17 décembre 1996, révisée le 11 janvier 1999

Cette version : | http://www.w3.org/TR/1999/REC-CSS1-19990111
Dernière version : | http://www.w3.org/TR/REC-CSS1
Version précédente : | http://www.w3.org/TR/REC-CSS1-961217
Auteurs : | Håkon Wium Lie (howcome@w3.org) Bert Bos (bert@w3.org)

Statut de ce document

Ce document est une recommandation du W3C. Il a été vérifié par les membres du W3C et l'utilisation de cette spécification a été approuvée par consensus général. Ce document est stable et peut être considéré comme document de référence ou cité par un autre document comme norme de référence. Le W3C encourage un large déploiement de cette recommandation.

On peut trouver une liste actuelle des recommandations et autres documents techniques du W3C à l'adresse http://www.w3.org/TR/.

Ceci est une version corrigée du premier document publié le 17 décembre 1996. Les modifications apportées à la version originale sont répertoriées à l'Annexe F. Une liste des erreurs connues dans cette spécification est disponible à l'adresse http://www.w3.org/Style/CSS/Errata/REC-CSS1-19990111-errata →vf

Résumé

Ce document spécifie le niveau 1 du mécanisme des feuilles de style en cascade. Le langage CSS1 constitue un mécanisme de feuille de style simple qui permet aux auteurs et aux lecteurs de lier un style (par exemple les polices de caractères, les couleurs et l'espacement) à un document HTML. Le langage CSS1 peut être lu et écrit par un humain, les styles sont exprimés dans la terminologie habituelle de la publication par ordinateur.

La cascade des feuilles de style est une des caractéristiques fondamentales de CSS ; les auteurs peuvent attacher une feuille de style préférée tandis que les lecteurs ont la possibilité de choisir une feuille de style personnelle pour pallier un handicap physique ou technologique. Cette spécification définit les règles de résolution des conflits entre différentes feuilles de style.

Cette recommandation est le résultat des travaux du W3C dans le domaine des feuilles de style. Pour des informations complémentaires sur les feuilles de style, voir [1].

Table des matières

Résumé
La terminologie

1 Les notions de base
1.1 L'incorporation dans HTML
1.2 Le regroupement
1.3 L'héritage
1.4 Une classe comme sélecteur
1.5 Un ID comme sélecteur
1.6 Les sélecteurs contextuels
1.7 Les commentaires
2 Les pseudo-classes et les pseudo-éléments
2.1 Les pseudo-classes d'ancre
2.2 Les pseudo-éléments typographiques
2.3 Le pseudo-élément 'first-line'
2.4 Le pseudo-élément 'first-letter'
2.5 Les pseudo-éléments dans les sélecteurs
2.6 Les pseudo-éléments multiples
3 La cascade
3.1 'important'
3.2 L'ordre de cascade
4 Le modèle de mise en forme
4.1 Les éléments de type bloc
4.1.1 La mise en forme verticale
4.1.2 La mise en forme horizontale
4.1.3 Les éléments de liste
4.1.4 Les éléments flottants
4.2 Les éléments de type en-ligne
4.3 Les éléments remplacés
4.4 La hauteur de ligne
4.5 Le canevas
4.6 L'élément 'BR'
5 Les propriétés de CSS1
5.1 La notation des valeurs de propriété
5.2 Les propriétés des polices
5.2.1 L'ajustement des polices
5.2.2 'font-family'
5.2.3 'font-style'
5.2.4 'font-variant'
5.2.5 'font-weight'
5.2.6 'font-size'
5.2.7 'font'
5.3 Les propriétés de couleur et de fond
5.3.1 'color'
5.3.2 'background-color'
5.3.3 'background-image'
5.3.4 'background-repeat'
5.3.5 'background-attachment'
5.3.6 'background-position'
5.3.7 'background'
5.4 Les propriétés du texte
5.4.1 'word-spacing'
5.4.2 'letter-spacing'
5.4.3 'text-decoration'
5.4.4 'vertical-align'
5.4.5 'text-transform'
5.4.6 'text-align'
5.4.7 'text-indent'
5.4.8 'line-height'
5.5 Propriétés de boîte
5.5.1 'margin-top'
5.5.2 'margin-right'
5.5.3 'margin-bottom'
5.5.4 'margin-left'
5.5.5 'margin'
5.5.6 'padding-top'
5.5.7 'padding-right'
5.5.8 'padding-bottom'
5.5.9 'padding-left'
5.5.10 'padding'
5.5.11 'border-top-width'
5.5.12 'border-right-width'
5.5.13 'border-bottom-width'
5.5.14 'border-left-width'
5.5.15 'border-width'
5.5.16 'border-color'
5.5.17 'border-style'
5.5.18 'border-top'
5.5.19 'border-right'
5.5.20 'border-bottom'
5.5.21 'border-left'
5.5.22 'border'
5.5.23 'width'
5.5.24 'height'
5.5.25 'float'
5.5.26 'clear'
5.6 Les propriétés de classification
5.6.1 'display'
5.6.2 'white-space'
5.6.3 'list-style-type'
5.6.4 'list-style-image'
5.6.5 'list-style-position'
5.6.6 'list-style'
6 Les unités
6.1 Les unités de longueur
6.2 Les unités de pourcentage
6.3 Les unités de couleur
6.4 Les adresses URL
7 La conformité à CSS1
7.1 La compatibilité ascendante de l'interprétation
8 Références
9 Remerciements

Annexe A : Exemple de feuille de style pour HTML 2.0
Annexe B : Grammaire de CSS1
Annexe C : Codage
Annexe D : Correction du gamma
Annexe E : Conditions d'utilisation et capacité d'extension de CSS1
Annexe F : Changements depuis la version du 17 décembre 1996

La terminologie

agent (d')utilisateur
un agent utilisateur, souvent un navigateur ou un client Web.
attribut
attribut HTML
auteur
l'auteur d'un document HTML
balisage fictif
un moyen pour décrire le comportement des pseudo-classes et des pseudo-éléments.
canevas
la surface dessinée par l'agent utilisateur sur laquelle un document est rendu
CSS1
CSS niveau 1. Ce document définit le langage CSS1 qui est un mécanisme de feuille de style simple pour le Web.
déclaration
une propriété (ex. 'font-size') et sa valeur correspondante (ex. '12pt').
designer
l'auteur d'une feuille de style.
dimensions intrinsèques
la largeur et la hauteur définies par le seul élément, non imposées par son environnement. On considère dans cette spécification que tous les éléments remplacés, et seulement ceux-ci, ont des dimensions intrinsèques.
document
un document HTML.
élément
un élément HTML.
élément de type bloc
un élément qui a une fin de ligne avant et après (ex. 'H1' en HTML)
élément de type en-ligne
un élément qui n'a pas de fin de ligne avant ni après (ex. 'STRONG' en HTML)
élément remplacé
un élément dont l'interpréteur de CSS ne connaît que les dimensions intrinsèques. En HTML,'IMG', 'INPUT', 'TEXTAREA', 'SELECT' et 'OBJECT' sont des exemples d'éléments remplacés. Par exemple, le contenu de l'élément 'IMG' est souvent remplacé par l'image que l'attribut 'SRC' indique. CSS1 ne définit pas comment sont trouvées les dimensions intrinsèques.
élément enfant (ou enfant)
un sous-élément dans la terminologie SGML [5]
élément parent ou parent
l'élément contenant dans la terminologie SGML [5].
extension HTML
Balisage introduit par les compagnies éditrices d'agents utilisateurs, le plus souvent pour obtenir des effets visuels. Les balises 'FONT', 'CENTER' et 'BLINK' en sont des exemples, ainsi que l'attribut 'BGCOLOR'. Un des buts des feuilles de style est de fournir une alternative aux extensions HTML.
feuille de style
un ensemble de règles
feuille de style ou Cascading Style Sheets
les feuilles de style en cascade et leur format
fonctions avancées de CSS1
caractéristiques décrites dans cette spécification mais qui n'appartiennent pas aux fonctions de base de CSS1.
fonctions de base de CSS1
la partie de CSS1 obligatoire pour tous les agents utilisateurs conformes à CSS1.
HTML
Hypertext Markup Language [2] une application de SGML.
interpréteur CSS1
un agent utilisateur qui lit les feuilles de style CSS1.
lecteur
la personne qui consulte le document.
poids
l'importance relative d'une règle, son ordre de priorité.
propriété
un paramètre de style sur lequel peut agir une feuille de style. Cette spécification définit une liste de propriétés et leurs valeurs associées.
pseudo-élément
les pseudo-éléments qui sont utilisés par les sélecteurs de CSS pour agir sur des éléments typographiques (ex. la première ligne d'un élément) plutôt que sur les éléments structuraux proprement dits.
pseudo-classe
les pseudo-classes qui sont utilisées par les sélecteurs de CSS permettent des indications en supplément de la source HTML (ex. un lien a été visité ou non) pour la classification des éléments.
règle
une déclaration (ex. 'font-family: helvetica') et son sélecteur (ex. 'H1').
sélecteur
une chaîne de caractères qui identifie les éléments sur lesquels s'applique la règle correspondante. Un sélecteur est ou bien simple (ex. 'H1') ou bien contextuel (fait de plusieurs sélecteurs simples, p.ex. 'H1 B').
sélecteur contextuel
un sélecteur qui agit sur les éléments selon leur position dans la structure du document. Un sélecteur contextuel consiste en plusieurs sélecteurs simples. Par exemple, le sélecteur contextuel 'H1.initial B' est constitué des deux sélecteurs simples 'H1.initial' et 'B'.
sélecteur simple
un sélecteur qui identifie un élément par son type et/ou son attribut et non par la position de celui-ci dans la structure du document (ex. 'H1.initial' est un sélecteur simple).
SGML
Standard Generalized Markup Language [5], HTML en est une application.
taille ou corps de police
La taille du dessin d'une police. Typiquement, le corps d'une police est à peu près égal à la distance entre le bas de la lettre avec jambage la plus basse et le haut de la lettre avec hampe la plus haute avec éventuellement un accent diacritique.
type d'élément
un identifiant générique dans la terminologie SGML [5].
utilisateur
synonyme de lecteur

Tout au long de ce texte, l'utilisation de guillemets simples ('...') correspond à des extraits de code HTML ou CSS.

1 Les notions de base

Créer une feuille de style simple est facile. On a besoin de connaître un peu de HTML et quelques termes de base de la publication par ordinateur. Par exemple, pour rendre bleu les éléments 'H1', on écrit :

H1 { color: blue }

L'exemple ci-dessus est une simple règle CSS. Une règle consiste en deux parties : un sélecteur ('H1') et une déclaration ('color: blue'). La déclaration comprend deux parties : la propriété ('color') et la valeur associée ('blue'). Bien que cet exemple n'agisse que sur une seule des propriétés nécessaires au rendu d'un document HTML, cela suffit pour qu'elle soit qualifiée de feuille de style. Combinée avec d'autres feuilles de style (la combinaison de feuilles de style est une fonction fondamentale des CSS), elle agira sur la présentation finale du document.

Le sélecteur est le lien entre le document HTML et la feuille de style, tous les types d'éléments HTML pouvant être des sélecteurs. Les types d'éléments HTML sont définis dans la spécification du HTML [2].

La propriété 'color' fait partie de la cinquantaine de propriétés qui déterminent la présentation d'un document HTML. La liste des propriétés et leurs valeurs possibles est définie dans cette spécification.

Les auteurs HTML ne devraient écrire des feuilles de style que pour suggérer un style particulier à leurs documents. Chaque agent utilisateur (navigateur ou client Web) est pourvu d'une feuille de style par défaut qui présente les documents d'une manière (sinon banale) tout au moins raisonnable. L'annexe A contient un exemple de feuille de style pour la présentation de documents HTML tel que suggéré dans la spécification du HTML 2.0 [3].

La grammaire formelle du langage CSS1 est définie dans l'annexe B.

1.1 L'incorporation dans HTML

Pour que les feuilles de style puissent avoir une influence sur la présentation, les agents utilisateurs doivent en connaître l'existence. La spécification HTML [2] définit la façon de relier HTML aux feuilles de style. Ce chapitre est donc informatif et non normatif :

<HTML>
  <HEAD>
    <TITLE>Titre</TITLE>
    <LINK REL=STYLESHEET TYPE="text/css"
      HREF="http://style.com/cool" TITLE="Cool">
    <STYLE TYPE="text/css">
      @import url(http://style.com/basic);
      H1 { color: blue }
    </STYLE>
  </HEAD>
  <BODY>
    <H1>Ce titre est en bleu</H1>
    <P STYLE="color: green">et le paragraphe est en vert.
  </BODY>
</HTML>

L'exemple montre quatre façons de combiner le style au HTML : avec l'élément 'LINK' vers une feuille de style externe, avec l'élément 'STYLE' à l'intérieur de l'élément 'HEAD', avec une feuille de style importée à l'aide de la notation CSS '@import' et enfin avec l'attribut 'STYLE' d'un élément (ici 'P') dans 'BODY'. Cette dernière option mélange style et contenu, et on perd de ce fait les avantages d'une feuille de style traditionnelle.

L'élément 'LINK' fait référence à des feuilles de style alternatives que le lecteur peut sélectionner, alors que les feuilles de style importées sont automatiquement combinées avec les autres feuilles de style.

En pratique, les agents utilisateurs ignorent les balises qui leur sont inconnues. Une conséquence, les vieux agents utilisateurs ignoreront l'élément 'STYLE', mais non son contenu qui sera traité comme faisant partie du corps du document, et qui sera rendu comme tel. Pendant une période transitoire, le contenu de l'élément 'STYLE' peut être caché à l'aide de commentaires SGML :

<STYLE TYPE="text/css"><!--
  H1 { color: green }
--></STYLE>

Comme l'élément 'STYLE' est déclaré dans le DTD en tant que "CDATA" (défini dans [2]), les interpréteurs conformes à SGML ne confondront pas la feuille de style avec un commentaire et en tiendront donc compte.

1.2 Le regroupement

Pour réduire la taille des feuilles de style, on peut grouper des sélecteurs dans une liste en les séparant par des virgules :

H1, H2, H3 { font-family: helvetica }

De même, on peut grouper les déclarations :

H1 {
  font-weight: bold;
  font-size: 12pt;
  line-height: 14pt;
  font-family: helvetica;
  font-variant: normal;
  font-style: normal;
}

De plus, quelques propriétés ont leur propre syntaxe de regroupement :

H1 { font: bold 12pt/14pt helvetica }

qui équivaut à l'exemple précédent.

1.3 L'héritage

Dans le premier exemple, on donnait une couleur bleu aux éléments de 'H1'. Supposons qu'il y ait un élément mis en exergue parmi ceux compris dans l'élément 'H1' :

<H1>Le titre <EM>est</EM> important !</H1>

Si aucune couleur n'a été assignée à l'élément 'EM', le "est" mis en exergue hérite de la couleur de l'élément parent, il apparaît donc en bleu. D'autres propriétés de style sont pareillement héritées, par exemple 'font-family' et 'font-size'.

Pour donner une propriété de style par "défaut" à un document, on peut assigner la propriété à un élément dont tous les éléments visibles descendent. Dans les documents HTML, l'élément 'BODY' peut servir à cet usage :

BODY {
  color: black;
  background: url(texture.gif) white;
}

Ceci fonctionne, même si l'auteur omet la balise 'BODY' (ce qui est autorisé), l'interpréteur HTML inférant la balise manquante. L'exemple ci-dessus donne un rendu du texte en noir et une image de fond. Le fond sera blanc si l'image n'est pas disponible (cf. chapitre 5.3 pour plus d'infos).

Quelques propriétés de style ne sont pas transmises de l'élément parent à l'élément enfant. Le plus souvent, on constate intuitivement quand ce n'est pas le cas. Par exemple, la propriété 'background' n'est pas héritée, mais le fond de l'élément parent transparaîtra par défaut.

Souvent, la valeur d'une propriété est un pourcentage de celle d'une autre propriété :

P { font-size: 10pt }
P { line-height: 120% }  /* relatif à 'font-size', c-à-d 12pt */

Pour toute propriété qui admet des valeurs en pourcentage est déterminée la propriété à laquelle elle se réfère. Les éléments enfants de 'P' hériteront de la valeur calculée de 'line-height' (c.à.d 12pt), et non du pourcentage.

1.4 Une classe comme sélecteur

Pour accroître la granularité de l'action sur les éléments, un nouvel attribut a été ajouté à HTML [2]: 'CLASS'. Tous les éléments à l'intérieur d'un élément 'BODY' peuvent appartenir à une classe, celle-ci étant déclarée dans la feuille de style :

<HTML>
 <HEAD>
  <TITLE>Titre</TITLE>
  <STYLE TYPE="text/css">
    H1.pastoral { color: #00FF00 }
  </STYLE>
 </HEAD>
 <BODY>
  <H1 CLASS=pastoral>Beaucoup trop vert</H1>
 </BODY>
</HTML>

Les règles d'héritage habituelles s'appliquent aux éléments définis avec une classe ; ils héritent des valeurs de leur parent dans la structure du document.

On peut adresser tous les éléments d'une même classe sans pour autant mettre le nom de la balise dans le sélecteur :

.pastoral { color: green }  /* tous les éléments de la classe pastoral */

On ne peut spécifier qu'une seule classe par sélecteur. Ainsi 'P.pastoral.marine' est un sélecteur invalide en CSS1 (les sélecteurs contextuels décrits plus bas peuvent avoir une classe par sélecteur simple)

Les feuilles de style CSS confèrent tant de pouvoir à l'attribut CLASS que, dans de nombreux cas, l'élément sur laquelle porte la classe importe peu ; quel que soit l'élément, vous pouvez presque le faire se comporter comme un autre. Une telle utilisation n'est pas recommandée car on supprime un niveau de structure qui a une signification universelle (éléments HTML). Une structure basée sur CLASS n'a d'utilité que dans un domaine restreint où la signification d'une classe peut reposer sur un accord mutuel.

1.5 Un ID comme sélecteur

HTML [2] introduit aussi l'attribut 'ID' qui garantit le caractère d'unicité d'un objet dans un document. Il peut revêtir un intérêt particulier en tant que sélecteur dans la feuille de style, où on l'adresse en le faisant précéder d'un dièse '#' :

#z98y { letter-spacing: 0.3em }
H1#z98y { letter-spacing: 0.5em }

<P ID=z98y>Texte espacé</P>

Dans l'exemple ci-dessus, le premier sélecteur vise l'élément 'P' en raison de la valeur de l'attribut 'ID'. Le second sélecteur spécifie à la fois un type d'élément ('H1') et une valeur d'ID, il ne concernera donc pas l'élément 'P'.

En utilisant l'attribut ID comme sélecteur, on peut fixer des propriétés de style par élément. Alors que les feuilles de style sont avant tout destinées à améliorer la structure du document, cette fonction donne aux auteurs la possibilité de créer des documents de bonne présentation dans la page mais sans tirer avantage des éléments structuraux de HTML. Cette utilisation des feuilles de style n'est donc pas encouragée.

1.6 Les sélecteurs contextuels

L'aptitude à hériter de CSS épargne les doigts des auteurs. Au lieu de la mise en place de toutes les propriétés de style, on peut créer une feuille de style par défaut et l'amender d'une liste des exceptions. Pour donner une couleur différente aux éléments 'EM' inclus dans 'H1', on pourrait écrire :

H1 { color: blue }
EM { color: red }

La feuille de style prenant effet, toutes les sections mises en exergue dans et hors de 'H1' auront la couleur rouge. Peut-être voulait-on que seuls les éléments 'EM' dans 'H1' soient rouge, on pouvait le faire avec :

H1 EM { color: red }

Le sélecteur est devenu un motif de recherche sur la pile des éléments ouverts, on le nomme un sélecteur contextuel. Les sélecteurs contextuels sont composés d'une suite de plusieurs sélecteurs simples séparés par un espace (tous les sélecteurs décrits jusqu'ici étaient des sélecteurs simples). Seuls les éléments existants qui correspondent au dernier sélecteur simple de la suite (ici l'élément 'EM') sont concernés, et seulement si le motif de recherche correspond. Les sélecteurs contextuels en CSS1 sont liés à leurs ancêtres, mais l'évolution de la norme pourraient introduire d'autres relations (ex. parent-enfant). Dans l'exemple au-dessus, la reconnaissance était probante si 'EM' est un descendant de 'H1', c.-à-d. si 'EM' est à l'intérieur d'un élément 'H1'.

UL LI    { font-size: small }
UL UL LI { font-size: x-small }

Ici, le premier sélecteur correspond aux éléments 'LI' qui ont au moins un ancêtre 'UL'. Le second sélecteur correspond à un sous-ensemble du premier, où les éléments 'LI' ont au moins deux ancêtres 'UL'. Le conflit apparent est résolu par le fait que le motif de recherche du second sélecteur est plus long, et donc plus spécifique, que le premier. Voir l'ordre de cascade (chapitre 3.2) pour plus d'infos.

Les sélecteurs contextuels peuvent être spécifiés au travers des types d'élément, des attributs CLASS, des attributs ID ou d'une combinaison de ceux-ci :

DIV P           { font: small sans-serif }
.reddish H1     { color: red }
#x78y CODE      { background: blue }
DIV.sidenote H1 { font-size: large }

Le premier sélecteur correspond aux éléments 'P' qui ont un élément 'DIV' parmi leurs ancêtres. Le deuxième correspond aux éléments 'H1' qui ont un ancêtre de la classe 'reddish'. Le troisième aux éléments 'CODE' qui ont un parent dont l'attribut ID est égal à 'x78y'. Et le quatrième aux éléments 'H1' qui ont un ancêtre 'DIV', lui-même de la classe 'sidenote'.

On peut regrouper plusieurs sélecteurs contextuels :

H1 B, H2 B, H1 EM, H2 EM { color: red }

ce qui est équivalent à :

H1 B { color: red }
H2 B { color: red }
H1 EM { color: red }
H2 EM { color: red }

1.7 Les commentaires

Les commentaires textuels dans les feuilles de style CSS sont les mêmes que ceux employés pour le langage de programmation C [7] :

EM { color: red }  /* rouge, vraiment rouge ! */

Les commentaires ne peuvent pas être imbriqués. Un interpréteur CSS1 considère un commentaire comme un blanc.

2 Les pseudo-classes et les pseudo-éléments

En CSS1, un élément reçoit un style en fonction de sa position dans la structure du document. Ce modèle simple est suffisant pour une grande variété de styles, sauf pour quelques effets courants. Les concepts de pseudo-classes et de pseudo-éléments élargissent l'adressage et permettent à des directives externes d'influer sur la mise en forme.

Les sélecteurs CSS peuvent utiliser les pseudo-classes et pseudo-éléments, sans que ceux-ci n'apparaissent dans la source HTML. L'agent utilisateur les "insère" plutôt dans les feuilles de style, sous certaines conditions, lors de l'adressage. On les qualifie par commodité de "classes" et "éléments" pour décrire leur comportement. Plus particulièrement, on décrit leur mode opératoire à l'aide d'une séquence de balise fictive.

On utilise les pseudo-éléments pour adresser une partie d'un élément, les pseudo-classes permettent une distinction entre les styles des différents types d'élément de la feuille de style.

2.1 Les pseudo-classes d'ancre

Habituellement, les agents utilisateurs différencient à l'affichage les liens visités des liens non-visités. En CSS1, cela est fait par des pseudo-classes sur l'élément 'A' :

A:link { color: red }       /* lien non-visité */
A:visited { color: blue }   /* lien visité */
A:active { color: lime }    /* lien activé */

Tous les éléments 'A' avec un attribut 'HREF' vont recevoir le style d'un et un seul de ces groupes (les ancres avec un nom ne sont pas concernées). Les agents utilisateurs peuvent faire passer un élément de l'état 'visited' à 'link' après un temps non-précisé. L'état 'active' désigne un lien en train d'être sélectionné par l'utilisateur (clic maintenu sur la souris).

On peut assimiler l'action d'une pseudo-classe d'ancre à l'insertion manuelle d'une classe. L'agent utilisateur n'est pas obligé de redessiner la page déjà affichée pour tenir compte des transitions induites par une pseudo-classe d'ancre. Par exemple, une feuille de style peut très bien spécifier que la taille de la police 'font-size' d'un lien actif 'active' soit plus grande que celle d'un lien visité 'visited', ainsi l'agent utilisateur n'est pas tenu de reformater dynamiquement le document quand le lecteur clique sur un lien visité.

Les sélecteurs de pseudo-classe n'ont rien à voir avec les classes normales et vice versa. La règle de style qui suit sera inopérante :

A:link { color: red }

<A CLASS=link NAME=target5> ... </A>

En CSS1, les pseudo-classes d'ancre n'ont d'effet que sur l'élément 'A'. On pourra omettre le type d'élément du sélecteur :

A:link { color: red }
:link { color: red }

Les deux sélecteurs ci-dessus adressent les mêmes éléments en CSS1.

Le nom des pseudo-classes est insensible à la casse.

Les pseudo-classes sont utilisables dans les sélecteurs contextuels :

A:link IMG { border: solid blue }

On peut également utiliser les pseudo-classes en combinaison avec les classes normales :

A.external:visited { color: blue }

<A CLASS=external HREF="http://de.hors/">lien externe</A>

Si le lien avait été visité dans cet exemple, il apparaîtrait en bleu. Noter que le nom d'une classe normale précède le nom d'une pseudo-classe dans le sélecteur.

2.2 Les pseudo-éléments typographiques

Quelques effets typographiques courants ne sont pas associés aux éléments structuraux mais aux objets typographiques de la mise en page. Avec CSS1, deux objets typographiques peuvent être concernés par le biais de pseudo-éléments : la première lettre d'un élément et la première ligne d'un élément.

CSS1 de base : Les agents utilisateurs peuvent ignorer ces pseudo-éléments ':first-line' ou ':first-letter' dans un sélecteur, ou respecter toute ou partie de leurs propriétés. (Cf. le chapitre 7).

2.3 Le pseudo-élément 'first-line'

Le pseudo-élément 'first-line' est utilisé pour appliquer un style spécial à la première ligne issue de la mise en page :

<STYLE TYPE="text/css">
  P:first-line { font-variant: small-caps }
</STYLE>

<P>La première ligne d'un article dans un journal.

Un agent utilisateur en mode texte donnerait :

LA PREMIÈRE LIGNE D'UN ARTICLE
dans un journal.

La séquence de balise fictive dans cet exemple est :

<P>
<P:first-line>
La première ligne d'un article
</P:first-line>
dans un journal.
</P>

La balise fermante de 'first-line' est insérée à la fin de la première ligne telle qu'elle apparaît dans la mise en page.

Dans le cas où la première ligne d'un élément de type bloc A est aussi celle de l'élément B, ancêtre de A, la séquence de balise fictive est :

     <B>...
       <A>...
         <B:first-line>
           <A:first-line>
             Ceci est la première ligne
           </A:first-line>
         </B:first-line>
         ...
       </A>
       ...
     </B>

Toutes les balises fictives pour la première ligne se trouvent dans le plus petit élément englobant de type bloc, l'ordre d'imbrication des balises fictives A:first-line et B:first-line est le même que celui des éléments A et B.

La "première ligne formatée" d'un élément de type bloc correspond à la première ligne dans le flux de l'élément, c'est-à-dire en ignorant les flottants éventuels. Par exemple, dans cet extrait :

     <div>
       <p style="float: left">Un paragraphe flottant...</p>
       <p>La première ligne commence ici...</p>
     </div>

le sélecteur 'div:first-line' s'applique à la premiè ligne du second élément P, parce que le premier P est retiré du flux.

Le pseudo-élément 'first-line' ne s'applique qu'aux éléments de type bloc.

Le pseudo-élément 'first-line' se comporte comme un élément de type en-ligne avec quelques restrictions. Seules sont applicables à 'first-line' : les propriétés de police (5.2), les propriété de couleur et de fond (5.3), et les propriétés 'word-spacing' (5.4.1), 'letter-spacing' (5.4.2), 'text-decoration' (5.4.3), 'vertical-align' (5.4.4), 'text-transform' (5.4.5), 'line-height' (5.4.8), 'clear' (5.5.26).

2.4 Le pseudo-élément 'first-letter'

Le pseudo-élément 'first-letter' s'utilise pour obtenir des effets typographiques courants comme la "lettrine" ou le changement "en bas de casse". Si sa propriété 'float' a pour valeur 'none', il se comporte comme un élément de type en-ligne ou, sinon, comme un élément flottant. Voici les propriétés qui s'appliquent à 'first-letter' : les propriétés de police (5.2), de couleur et de fond (5.3), 'text-decoration' (5.4.3), 'vertical-align' (seulement si 'float' a comme valeur 'none', 5.4.4), 'text-transform' (5.4.5), 'line-height' (5.4.8), les propriétés de marge (5.5.1-5.5.5), d'espacement (5.5.6-5.5.10), de bordure (5.5.11-5.5.22), et les propriétés 'float' (5.5.25) et 'clear' (5.5.26).

Voici comment on pourrait faire une lettrine qui s'étend sur deux lignes :

<HTML>
 <HEAD>
  <TITLE>Titre</TITLE>
  <STYLE TYPE="text/css">
   P              { font-size: 12pt; line-height: 12pt }
   P:first-letter { font-size: 200%; float: left }
   SPAN           { text-transform: uppercase }
  </STYLE>
 </HEAD>
 <BODY>
  <P><SPAN>Les premiers</SPAN> mots d'un article de journal.</P>
 </BODY>
</HTML>

Une représentation (improbable) par un agent utilisateur en mode texte gérant le pseudo-élément 'first-letter' donnerait :

|  ES PREMIERS
|_ mots d'un
article de journal.

La séquence de balise fictive en est :

<P>
<SPAN>
<P:first-letter>
L
</P:first-letter>es premiers
</SPAN>
mots d'un article de journal.
</P>

Noter que les balises du pseudo-élément 'first-letter' butent contre le contenu (c.-à-d. le caractère initial), alors que la balise ouvrante du pseudo-élément 'first-line' s'insère juste après la balise ouvrante de l'élément qui le contient.

L'agent utilisateur détermine les caractères qui font partie de l'élément 'first-letter'. Normalement, il devrait inclure le guillemet éventuel qui précède la première lettre :

|||    | n tiens
  |    | vaut mieux
  |    | que deux
  |____| tu l'auras,"
dit un vieux proverbe.

Quand la première lettre d'un paragraphe est un autre signe de ponctuation (ex. parenthèse, ellipses) ou un autre caractère non assimilé à une lettre (ex. chiffres et symboles mathématiques), 'first-letter' est en général ignoré.

L'usage diffère selon les langues. Par exemple en hollandais, un mot qui commence par "ij" alors cette combinaison devrait être considérée dans son entier par 'first-letter'.

On ne peut lier le pseudo-élément 'first-letter' qu'à un élément de type bloc.

2.5 Les pseudo-éléments dans les sélecteurs

Dans un sélecteur contextuel, on ne peut mettre les pseudo-éléments qu'à la fin du sélecteur :

BODY P:first-letter { color: purple }

On peut combiner les pseudo-éléments avec des classes dans les sélecteurs :

P.initial:first-letter { color: red }

<P CLASS=initial>Premier paragraphe</A></P>

Dans cet exemple, la première lettre des éléments 'P' qui ont pour classe 'initial' est de couleur rouge. En combinaison avec des classes ou des pseudo-classes, on doit spécifier les pseudo-éléments à la fin du sélecteur. Il ne peut y avoir qu'un pseudo-élément par sélecteur.

2.6 Les pseudo-éléments multiples

On peut combiner plusieurs pseudo-éléments :

P { color: red; font-size: 12pt }
P:first-letter { color: green; font-size: 200% }
P:first-line { color: blue }

<P>Texte qui se poursuit sur deux lignes</P>

Dans cet exemple, la première lettre de chaque élément 'P' a une couleur verte et un corps de police 24pt. Le reste de la première ligne (selon le formatage de la page) a une couleur bleu, puis le reste du paragraphe une couleur rouge. En supposant qu'il y ait une fin de ligne avant le mot "poursuit", la séquence de balise fictive serait :

<P>
<P:first-line>
<P:first-letter>
T
</P:first-letter>exte qui se
</P:first-line>
poursuit sur deux lignes
</P>

Noter que l'élément 'first-letter' est placé à l'intérieur de l'élément 'first-line'. Les propriétés de 'first-line' seront héritées par 'first-letter', mais avec leurs valeurs remplacées par celles déclarées pour 'first-letter' si tel est le cas.

Si un pseudo-élément coupe un élément réel, des balises supplémentaires doivent nécessairement être recréées dans la séquence de balise fictive. Par exemple, si un élément 'SPAN' s'étend au-delà d'une balise </P:first-line>, alors un jeu de balise fermante et ouvrante sera créé, la séquence de balise fictive devient :

<P>
<P:first-line>
<SPAN>
Ce texte est à l'intérieur d'un
</SPAN>
</P:first-line>
<SPAN>
interminable élément 'SPAN'.
</SPAN>

3 La cascade

Avec CSS, la présentation peut être influencée simultanément par plusieurs feuilles de style. Deux raisons à cela : la modularité, et l'équilibre entre les prérogatives de l'auteur et du lecteur.

modularité
Un auteur peut combiner plusieurs feuilles de style (partielles) pour éviter la redondance :
@import url(http://www.style.org/pastoral);
@import url(http://www.style.org/marine);

H1 { color: red }     /* annule le style importé */
équilibre
Le lecteur et l'auteur peuvent tous deux agir sur la présentation au travers des feuilles de style. Pour cela, ils usent du même langage de feuille de style, ce qui illustre un aspect fondamental du Web : tout le monde peut publier. Le mécanisme de référencement des feuilles de style personnelles est laissé au choix de l'agent utilisateur.

Des conflits peuvent naître entre les feuilles de styles agissant sur la présentation. La résolution de ceux-ci est fondée sur un poids attribué à chaque règle. Les règles des feuilles de style du lecteur ont par défaut un poids moindre que celles des feuilles de style de l'auteur. C.-à-d., si un conflit apparaît entre les feuilles de style du lecteur et celles de l'auteur, les dernières auront la priorité. Les directives du lecteur et de l'auteur remplacent toutes deux les valeurs par défaut de l'agent utilisateur.

Les feuilles de style importées agissent aussi en cascade les unes avec les autres, dans l'ordre d'apparition, et selon les règles de cascade définies ci-dessous. Toutes règles spécifiées dans la feuille de style elle-même prennent le pas sur celles importées. C.-à-d., les feuilles de style importées sont placées plus bas dans l'ordre de cascade que les règles de la feuille de style. Ces feuilles de style importées peuvent à leur tour importer et surcharger d'autres feuilles de style récursivement.

En CSS1, toutes les déclarations '@import' doivent être placées au début de la feuille de style, avant toutes autres déclarations. Cela constitue un rappel visuel de la préséance des règles qui sont dans la feuille de style sur celles des feuilles de style importées.

3.1 'important'

L'auteur peut accroître le poids des règles de sa feuille de style :

H1 { color: black ! important; background: white ! important }
P  { font-size: 12pt ! important; font-style: italic }

Dans l'exemple ci-dessus, un poids supplémentaire est donné aux trois premières déclarations, la dernière gardant un poids normal.

La règle déclarée importante du lecteur est prioritaire sur celle normale de l'auteur. La règle déclarée importante de l'auteur annule celle importante du lecteur.

3.2 L'ordre de cascade

Les règles conflictuelles sont intrinsèques au mécanisme des CSS. L'algorithme suivant doit être respecté pour trouver la valeur d'une combinaison entre élément et/ou propriété :

  1. Trouver toutes les déclarations qui s'appliquent à l'élément ou la propriété en question. Les déclarations s'appliquent si le sélecteur concerne l'élément donné. Si aucune déclaration ne correspond, les valeurs héritées sont utilisées. S'il n'y en a pas (l'élément 'HTML' et autres propriétés qui ne sont pas héritées), alors utiliser la valeur initiale.
  2. Trier les déclarations selon leur poids explicite : les déclarations marquées '!important' ont plus de poids que celles non-marquées (normal).
  3. Trier selon l'origine : les feuilles de style de l'auteur surclassent celles du lecteur qui surclassent à leur tour les valeurs internes par défaut de l'agent utilisateur. Une feuille de style importée est considérée avoir la même origine que celle dont elle est issue.

  4. Trier selon la spécifité du sélecteur : un sélecteur général est surclassé par un sélecteur plus spécifique. Déterminer la spécificité en comptant le nombre d'attributs ID (a), le nombre d'attributs CLASS (b) et le nombre de noms de balise (c) dans le sélecteur. Rassembler ces trois nombres (dans un système de nombres sur une base étendue) pour obtenir la spécifité. Un exemple :

    LI            {...}  /* a=0 b=0 c=1 -> spécificité =   1 */
UL LI         {...}  /* a=0 b=0 c=2 -> spécificité =   2 */
UL OL LI      {...}  /* a=0 b=0 c=3 -> spécificité =   3 */
LI.red        {...}  /* a=0 b=1 c=1 -> spécificité =  11 */
UL OL LI.red  {...}  /* a=0 b=1 c=3 -> spécificité =  13 */
#x34y         {...}  /* a=1 b=0 c=0 -> spécificité = 100 */

    On considère respectivement les pseudo-classes et pseudo-éléments comme des classes et éléments normaux.

    Trier selon la spécificité du sélecteur : les sélecteurs plus spécifiques surclasseront ceux plus généraux. Pour trouver la spécificité d'un sélecteur ou de l'attribut 'STYLE' d'un élément (cf. section 1.1 pour un exemple), compter 1 si le sélecteur est dans l'attribut 'STYLE' et 0 sinon (a), compter le nombre d'attributs ID dans le sélecteur (b), le nombre d'attributs 'CLASS' dans le sélecteur (b) et le nombre de noms de balises dans le sélecteur (d). On obtient la spécificité en concaténant les quatres nombre (dans un système de nombre à grande base). Quelques exemples (triés des moins au plus spécifiques) :

    LI            {...}  /* a=0 b=0 c=0 d=1 -> specificité = 0,0,0,1 */
UL LI         {...}  /* a=0 b=0 c=0 d=2 -> specificité = 0,0,0,2 */
UL OL LI      {...}  /* a=0 b=0 c=0 d=3 -> specificité = 0,0,0,3 */
LI.red        {...}  /* a=0 b=0 c=1 d=1 -> specificité = 0,0,1,1 */
UL OL LI.red  {...}  /* a=0 b=0 c=1 d=3 -> specificité = 0,0,1,3 */
#x34y         {...}  /* a=0 b=1 c=0 d=0 -> specificité = 0,1,0,0 */
style="..."          /* a=1 b=0 c=0 d=0 -> specificité = 1,0,0,0 */

    Les pseudo-éléments et les pseudo-classes comptent respectivement comme des éléments et classes normaux.

  5. Trier dans l'ordre de spécification : si deux règles ont le même poids, alors la dernière l'emporte. Les règles importées sont considérées comme venant en premier dans la feuille de style elle-même.

La valeur d'une propriété est fixée dès que la règle de plus fort poids parmi celles qui s'appliquent à la même combinaison d'éléments/propriétés est trouvée.

Cette stratégie donne un poids considérable aux feuilles de styles d'un auteur. C'est pourquoi il est important que le lecteur puisse annuler l'influence de telle ou telle feuille de style, par exemple, choix au moyen d'un menu déroulant.

Une déclaration faite au moyen de l'attribut 'STYLE' d'un élément a le même poids que celle dans un sélecteur basé sur un ID (voir un exemple au chapitre 1.1) spécifié en fin de feuille de style :

<STYLE TYPE="text/css">
  #x97z { color: blue }
</STYLE>

<P ID=x97z STYLE="color: red">

Dans cet exemple, l'élément 'P' a la couleur rouge. Bien que les deux déclarations aient le même poids, celle de l'attribut 'STYLE' annule celle de l'élément 'STYLE' du fait de la règle de cascade numéro 5.

L'agent utilisateur peut honorer les autres attributs stylistiques propres au HTML, p.ex. 'ALIGN'. Dans ce cas, ils sont traduits dans leurs équivalents CSS avec une spécifité égale à 1. Ces règles induites sont placées en tête de la feuille de style de l'auteur et peuvent donc être remplacées par les règles écrites qui suivent. Cette façon de faire facilitera la coexistence des attributs stylistiques et des feuilles de style pendant une phase de transition.

4 Le modèle de mise en forme

CSS1 repose sur un modèle de mise en forme simple bâti sur un concept de boîtes dans lequel chaque élément formaté s'inscrit dans une ou plusieurs boîtes rectangulaires. Les éléments ayant une valeur 'none' pour la propriété 'display' n'ont pas de format et ne sont donc pas inscrits dans une telle boîte. Toutes les boîtes sont formées d'une aire avec un contenu de base entourée d'un espacement optionnel, d'une bordure et d'aires de marge.

 _______________________________________
|                                       |
|      marge [margin] (transparent)     |
|   _________________________________   |
|  |                                 |  |
|  |        bordure [border]         |  |
|  |   ___________________________   |  |
|  |  |                           |  |  |
|  |  |     espacement [padding]  |  |  |
|  |  |   _____________________   |  |  |
|  |  |  |                     |  |  |  |
|  |  |  |  contenu            |  |  |  |
|  |  |  |_____________________|  |  |  |
|  |  |___________________________|  |  |
|  |_________________________________|  |
|_______________________________________|

         |largeur de l'élément |
|         largeur de la boîte           |

Les tailles de la marge, de l'espacement et de la bordure sont fixées respectivement avec les propriétés 'margin' (5.5.1-5.5.5), 'padding' (5.5.6-5.5.10) et 'border' (5.5.11-5.5.22). La zone d'espacement est sur le fond de l'élément lui-même (spécifié par les propriétés de fond (5.3.2-5.3.7)). La couleur et le style de la bordure est donnée par les propriétés de bordure. Les marges sont toujours transparentes, on voit donc le parent de l'élément à travers.

La taille de la boîte est égale à la largeur de l'élément (c.-à-d. celle d'un texte formaté ou d'une image) et de l'espacement, auquel on ajoute la bordure et les marges.

Le formateur considère principalement deux genres d'élément : ceux de type bloc et ceux de type en-ligne.

4.1 Les éléments de type bloc

Les éléments qui ont une valeur 'block' ou 'list-item' pour la propriété 'display' sont des éléments de type bloc. On considère également de ce type les éléments flottants (dont la propriété 'float' a une valeur autre que 'none').

L'exemple suivant montre comment les marges et l'espacement régissent un élément 'UL' avec deux enfants. On a omis la bordure dans le schéma par souci de simplification. Les lettres faisant office de "constantes" ne font pas partie de la syntaxe CSS1, elles montrent juste le lien entre les valeurs de la feuille de style et le dessin.

<STYLE TYPE="text/css">
  UL {
    background: red;
    margin: A B C D;      /* marge */
    padding: E F G H;     /* espacement */
  }
  LI {
    color: white;
    background: blue;     /* le texte est blanc sur fond bleu */
    margin: a b c d;
    padding: e f g h;
  }
</STYLE>
..
<UL>
  <LI>1er élément de la liste
  <LI>2eme élément de la liste
</UL>

 _______________________________________________________
|                                                       |
|    A      UL margin (transparent)                     |
|    _______________________________________________    |
| D |                                               | B |
|   |    E   UL padding (rouge)                     |   |
|   |    _______________________________________    |   |
|   | H |                                       | F |   |
|   |   |    a   LI margin (transparent,        |   |   |
|   |   |        on voit le rouge au travers)   |   |   |
|   |   |    _______________________________    |   |   |
|   |   | d |                               | b |   |   |
|   |   |   |    e    LI padding (bleu)     |   |   |   |
|   |   |   |                               |   |   |   |
|   |   |   | h  1er élément de la liste  f |   |   |   |
|   |   |   |                               |   |   |   |
|   |   |   |    g                          |   |   |   |
|   |   |   |_______________________________|   |   |   |
|   |   |                                       |   |   |
|   |   |     max(a, c)                         |   |   | <- noter le max
|   |   |    _______________________________    |   |   |
|   |   |   |                               |   |   |   |
|   |   | d |    e    LI padding (bleu)     |   |   |   |
|   |   |   |                               |   |   |   |
|   |   |   | h  2eme élément de la liste f |   |   |   |
|   |   |   |                               |   |   |   |
|   |   |   |    g                          |   |   |   |
|   |   |   |_______________________________|   |   |   |
|   |   |                                       |   |   |
|   |   |   c    LI margin (transparent,        |   |   |
|   |   |        on voit le rouge au travers)   |   |   |
|   |   |_______________________________________|   |   |
|   |                                               |   |
|   |    G                                          |   |
|   |_______________________________________________|   |
|                                                       |
|   C                                                   |
|_______________________________________________________|

Techniquement, les propriétés d'espacement (N.D.T. padding) et de marge (N.D.T. margin) ne sont pas héritées. Mais, dans l'exemple, l'emplacement d'un élément est relatif à ses parents et à ses enfants, ainsi les propriétés d'espacement et de marge de ces éléments agissent sur leurs enfants.

S'il y avait eu des bordures, elles apparaîtraient entre l'espacement et les marges.

Le schéma suivant amène une terminologie utile :

                           --------------- <-- haut [top]
                            marge haute [margin-top]
                           ---------------
                            bordure haute [border-top]
                           ---------------
                            espacement haut [padding-top]
                           +-------------+ <-- bord interne haut
| marge  | bordure| espace.|             | espace. | bordure | marge   |
| gauche | gauche | gauche |-- contenu --| droit   | droite  | droite  |
|[margin |[border |[padding|             |[padding-|[border- |[margin- |
| -left] | -left] | -left] |             | right]  | right]  | right]  |
                           +-------------+ <-- bord interne bas
^                          ^             ^                             ^
bord       bord interne gauche      bord interne droit            bord
externe                                                                externe
gauche                      espacement bas [padding-bottom]            droit
                           ---------------
                            bordure bas [border-bottom]
                           ---------------
                             marge bas [margin-bottom]
                           --------------- <-- bas [bottom]

Le bord externe gauche représente le bord d'un élément, y compris l'espacement, la bordure et la marge. Le bord interne gauche représente le bord du seul élément, à l'exclusion de l'espacement, la bordure et la marge. Idem pour le côté droit. Le haut correspond au sommet de l'élément, y compris l'espacement, la bordure et la marge : il est seulement défini pour les éléments de type bloc et les éléments flottants, pas pour les éléments de type bloc non-flottants. Le bas correspond au bas de l'élément, y compris l'espacement, la bordure et la marge : il est seulement défini pour les élément de type bloc et les éléments flottants, pas pour les élément de type bloc non-flottants. Le bord interne bas représente le bas de l'élément, à l'exclusion de l'espacement, la bordure et la marge.

La largeur d'un élément est égale à la largeur du contenu, c.-à-d. la distance entre le bord interne gauche et le bord interne droit. Et sa hauteur est égale à la hauteur du contenu, c.-à-d. la distance entre le bord interne haut et le bord interne bas.

4.1.1 La mise en forme verticale

Pour les éléments de type bloc non-flottants, la largeur de la marge correspond à une distance minimum entre le contenu et le bord des boîtes qui l'entourent. Si aucune bordure, ni espacement, ni contenu ne séparent deux (ou plus) marges verticales adjacentes, alors elles fusionnent et la résultante est la plus grande de ces valeurs de marge. Dans la plupart des cas, cette fusion des marges verticales donne un meilleur aspect visuel, plus proche des attentes de l'auteur. Dans l'exemple précédent, les marges entre les deux éléments 'LI' ont fusionné et la marge résultante prend la valeur la plus grande entre celle de 'margin-bottom' du premier élément 'LI' et celle de 'margin-top' du second élément 'LI'. Pareillement, si l'espacement entre le 'UL' et le premier élément 'LI' (constante "E") avait été nul, les marges des éléments 'UL' et du premier 'LI' auraient fusionné.

Cas des marges négatives : la valeur maximale absolue entre marges négatives adjacentes est déduite de la plus grande valeur des marges positives. S'il n'y a pas de marges positives, alors la valeur maximale absolue d'entre les marges négatives est déduite de zéro.

4.1.2 La mise en forme horizontale

L'emplacement horizontal et la taille d'un élément de type bloc non-flottant sont déterminés par sept propriétés : 'margin-left', 'border-left', 'padding-left', 'width', 'padding-right', 'border-right' et 'margin-right'. La somme des sept valeurs associées est toujours égale à la valeur de 'width' du parent de l'élément.

Par défaut, la propriété 'width' d'un élément a pour valeur 'auto'. Si ce n'est pas un élément remplacé (ex. IMG), cela implique de la part de l'agent utilisateur l'addition des valeurs des sept propriétés citées ci-dessus pour arriver à la valeur de 'width' du parent. Si c'est un élément remplacé, la valeur 'auto' de 'width' devient automatiquement celle de la largeur intrinsèque de cet élément.

Trois de ces sept propriétés peuvent prendre la valeur 'auto' : 'margin-left', 'width' et 'margin-right'. Pour les éléments remplacés, la valeur 'auto' de 'width' étant remplacée par leur largeur intrinsèque, il ne leur reste donc que deux propriétés pouvant avoir la valeur 'auto'.

La propriété 'width' a une valeur minimum positive propre à l'agent utilisateur (variant d'un élément à un autre et pouvant dépendre d'autres propriétés). Si la valeur calculée devient inférieure à cette limite, qu'elle soit déclarée explicitement ou à 'auto', et que les règles suivantes la rendent trop petite, elle prendrait cette valeur limite.

Si une et une seule parmi 'margin-left', 'width' ou 'margin-right' a la valeur 'auto', l'agent utilisateur assigne à cette propriété-ci une valeur telle que la somme des sept propriétés soit égale à la largeur du parent.

Si aucune de ces trois propriétés n'a la valeur 'auto', alors la valeur de 'margin-right' passe à 'auto'.

Si plus d'une de ces trois propriétés ont la valeur 'auto', l'une d'elles étant 'width', alors les deux autres ('margin-left' et/ou 'margin-right') prennent la valeur zéro et 'width' une valeur telle que la somme des sept soit égale à la largeur du parent.

Autrement, si 'margin-left' et 'marging-right' ont la valeur 'auto', alors ces deux propriétés reçoivent la même valeur. De cette façon, l'élément est centré dans son parent.

Si une des sept propriétés d'un élément de type en-ligne ou flottant a la valeur 'auto', la valeur de cette propriété-ci devient nulle.

À la différence des marges verticales, les marges horizontales ne fusionnent pas.

4.1.3 Les éléments de liste

Les éléments dont la propriété 'display' a la valeur 'list-item' ont un format de type bloc, mais avec la marque de liste qui les précède. La propriété 'list-style' détermine le type de la marque. La position de cette marque dépend de la valeur de la propriété 'list-style' :

<STYLE TYPE="text/css">
  UL         { list-style: outside }
  UL.compact { list-style: inside }
</STYLE>

<UL>
  <LI>le premier article vient avant
  <LI>le second article vient après
</UL>

<UL CLASS=COMPACT>
  <LI>le premier article vient avant
  <LI>le second article vient après
</UL>

Ce qui apparaît ainsi :

* le premier article
  vient devant

* le second article
  vient après

  * le premier
  article vient avant

  * le second
  article vient après

Avec un sens de lecture de droite à gauche, les marques seraient du côté droit de la boîte.

4.1.4 Les éléments flottants

Avec une propriété 'float', un élément sort du flux normal des autres éléments et acquiert un format de type bloc. Par exemple, en donnant la valeur 'left' à la propriété 'float' d'une image, celle-ci est repoussée vers la gauche jusqu'à buter sur les marges, espacements ou bordures d'un autre élément de type bloc. Le flux normal se déroule sur le côté droit de l'image. Ses marges, bordures et espacements sont respectés, cependant les marges ne fusionnent jamais avec celles des éléments adjacents.

La position d'un élément flottant obéit aux contraintes suivantes (voir le chapitre 4.1 pour le sens des termes) :

  1. Le bord externe gauche d'un élément flottant à gauche ne peut se trouver plus à gauche que le bord interne gauche de son parent. Et inversement pour un élément flottant à droite.
  2. Le bord externe gauche d'un élément flottant à gauche doit se trouver sur la droite du bord externe droit de tout élément flottant à gauche qui précède (dans l'ordre de la source HTML) ou encore le sommet du suivant doit se trouver sous le bas du précédent. Et inversement pour les éléments flottants à droite.
  3. Le bord externe droit d'un élément flottant à gauche ne peut pas se trouver à droite du bord externe gauche d'éléments flottants à droite situés à sa droite. Et inversement pour un élément flottant à droite.
  4. Le sommet d'un élément flottant ne peut être plus haut que le bord haut interne de son parent.
  5. Le sommet d'un élément flottant ne peut être plus haut que celui d'un élément flottant ou de type bloc qui le précèdent.
  6. Le sommet d'un élément flottant ne peut être plus haut que le sommet d'une quelconque boîte de ligne avec contenu (cf. chapitre 4.4) qui le précède dans la source HTML.
  7. Un élément flottant est placé aussi haut que possible.
  8. Un élément flottant à gauche doit être placé aussi à gauche que possible, et inversement pour un élément flottant à droite. Un emplacement au plus haut est préférable à celui décalé sur la gauche ou la droite.
<STYLE TYPE="text/css">
  IMG { float: left }
  BODY, P, IMG { margin: 2em }
</STYLE>

<BODY>
  <P>
    <IMG SRC=img.gif>
    Un échantillon de texte qui...
</BODY>

Voici ce que donnerait l'exemple :

 ________________________________________
|
|          max(BODY margin, P margin)
|          ______________________________
|    |    |             Un échantillon de
| B  | P  | IMG margins texte qui n'a d'autre
| O  |    |    _____    but que de montrer
| D  | m  |   |     |   comment les éléments
| Y  | a  |   | IMG |   flottants butent contre
|    | r  |   |     |   les bords de leur parent
| m  | g  |   |_____|   en honorant les marges
| a  | i  |             bordures et espacements.
| r  | n  |             Noter comment les marges
| g  |    |verticales adjacentes ont fusionné
| i  |    |entre des éléments flottants
| n  |    |de type bloc.
|    |    |

Noter comment la marge de l'élément 'P' enserre l'élément flottant 'IMG'.

Deux situations peuvent se présenter où des éléments flottants peuvent recouvrir de leurs marges, bordures et espacements les emplacements d'autres éléments :

  • quand l'élément flottant a une marge négative ; les marges négatives de ces éléments sont respectées comme pour les autres éléments de type bloc.
  • quand l'élément flottant est plus large ou plus haut que son parent.

4.2 Les éléments de type en-ligne

Les éléments qui n'ont pas un format de type bloc sont des éléments de type en-ligne. Un élément en-ligne peut partager l'étendue de la ligne avec d'autres éléments. Un exemple :

<P>Plusieurs mots <EM>mis en exergue</EM> sont <STRONG>visibles</STRONG>.</P>

L'élément 'P' est de type bloc, alors que 'EM' et 'STRONG' sont de type en-ligne. Si l'élément 'P' est suffisamment large pour contenir le tout sur une ligne, ces deux éléments en-ligne sont donc sur celle-ci :

Plusieurs mots mis en exergue sont visibles.

S'il manque de place sur une ligne, un élément en-ligne est partagé en plusieurs boîtes :

<P>Il y a plusieurs <EM>mots mis en exergue</EM> ici.</P>

ce qui est illustré par :

Il y a plusieurs mots
mis en exergue ici.

Si l'élément en-ligne a des marges, bordures, espacements ou des décorations de texte qui lui sont associés, ces propriétés n'ont aucun effet à l'endroit où intervient une coupure de l'élément :

                  ----------
Il y a plusieurs |mots
                  ----------
---------
mis en exergue| ici.
---------

(Le dessin à partir de lettres est légèrement distordu. Voir le chapitre 4.4 sur la manière de calculer la hauteur des lignes).

4.3 Les éléments remplacés

On appelle élément remplacé un élément auquel est substitue un contenu désigné depuis l'intérieur même de celui-ci. Par exemple en HTML, l'élément 'IMG' est remplacé par une image référencée par l'attribut 'SRC'. L'élément substitué est censé apporter ses dimensions intrinsèques. Si la propriété 'width' a la valeur 'auto', la largeur de l'élément sera celle de la valeur de la largeur intrinsèque. Si on spécifie une valeur autre que 'auto' dans la feuille de style, c'est celle-ci qui est retenue pour dimensionner l'élément substitué (la méthode de dimensionnement dépendra du type du contenu référencé). La propriété 'height' est utilisée de la même façon.

Les éléments remplacés sont aussi bien de type bloc que en-ligne.

4.4 La hauteur de ligne

Tous les éléments ont une propriété 'line-height' qui est en principe la hauteur totale d'une ligne de texte. Dans la ligne, le texte reçoit un espace complémentaire au-dessus et en-dessous de celui-ci pour atteindre la valeur de la hauteur de ligne. Par exemple, si le texte a un corps de 12pt et la valeur de 'line-height' est 14pt, il est réparti un complément de 2pt entre le dessus (1pt) et le dessous (1pt) de la ligne. Ce calcul dépend des éléments, qu'ils aient un contenu ou non.

On appelle interligne (N.D.T. leading) la différence entre le corps de la police et la hauteur de la ligne, sa moitié se nomme demi-interligne. Après mise en forme, chaque ligne prend la forme d'une boîte de ligne (N.D.T. line-box) rectangulaire.

Si une ligne contient des parties dont les valeurs pour 'line-height' sont différentes (c'est qu'elle contient des éléments en-ligne), alors chacune de ces parties a sa propre demi-interligne au-dessus et au-dessous. La hauteur de la boîte de ligne s'étend du sommet de l'élément le plus haut au bas de l'élément le plus bas. Noter que le sommet et le bas de la ligne ne correspondent pas forcément à l'élément de plus grande hauteur, car la position dans le sens vertical d'un élément dépend aussi de sa propriété 'vertical-align'. Chaque boîte de ligne est empilée immédiatement sous la ligne précédente pour former un paragraphe.

Noter qu'espacement, bordure et marge du dessus et du dessous d'un élément en-ligne mais qui n'est pas remplacé n'influencent pas la hauteur de la ligne. C.-à-d., si la valeur de 'line-height' est trop petite pour l'espacement et la bordure choisie, l'élément risque de recouvrir le texte des autres lignes.

Dans une ligne, les éléments remplacés (ex. images) peuvent agrandir la boîte de ligne si son sommet (espacements, bordures et marges inclus) est plus haut que le sommet de la partie texte ou si son bas est en dessous du bas de ce même texte.

En temps normal, quand il n'y a qu'une seule valeur pour 'line-height' dans tout un paragraphe, sans images trop hautes, cette définition garantie que la base du texte des lignes successives est dissociée de 'line-height'. C'est important quand des colonnes de texte avec différentes polices doivent être alignées, dans une table par exemple.

Noter que ceci n'empêche pas le texte sur deux lignes adjacentes de se recouvrir. La valeur de 'line-height' peut être plus petite que la hauteur du texte ce qui traduit un interlignage négatif. Cela peut être utile si on sait que le texte ne contient pas de caractères avec jambage (ex. texte tout en capitales), on peut ainsi rapprocher les lignes entre elles.

4.5 Le canevas

On appelle canevas la partie de la surface affichée par l'agent utilisateur sur laquelle le document est représenté. Aucun élément de structure ne correspond à cette définition, ce qui amène deux questions au moment de la mise en forme d'un document :

  • quel est le repère à partir duquel établir les dimensions du canevas ?
  • si un document ne recouvre pas le canevas en son entier, comment rendre cet espace non occupé ?

À la première question, la raison veut que la largeur initiale du canevas soit basée sur la largeur de la fenêtre, cependant CSS1 ne répond pas à cette interrogation laissant l'agent utilisateur décider. On peut attendre de l'agent utilisateur qu'il modifie la largeur du canevas quand on redimensionne la fenêtre, mais ce n'est pas le but de CSS1 non plus.

À la deuxième question, on a le précédent des extensions HTML : les attributs de l'élément 'BODY' qui fixent les valeurs de fond de tout le canevas. Pour répondre aux souhaits des auteurs, CSS1 introduit une règle spéciale pour trouver le fond du canevas :

Utiliser la valeur de la propriété 'background' de l'élément 'HTML' si elle est différente de 'transparent', sinon prendre la valeur de 'background' de l'élément 'BODY'. Si cette valeur est 'transparent', alors le rendu n'est pas défini.

Cette règle permet cette construction :

<HTML STYLE="background: url(http://style.com/marble.png)">
<BODY STYLE="background: red">

Ici, le canevas est couvert par l'image "marble.png". Le fond de l'élément 'BODY' (qui recouvre complètement ou non le canevas) est rouge.

Comme on ne dispose pas encore de moyen pour adresser directement le canevas, il est recommandé de reporter les propriétés souhaitées pour celui-ci sur l'élément 'BODY'.

4.6 L'élément 'BR'

Le comportement de l'élément 'BR' n'est pas décrit par les propriétés et valeurs de CSS1. En HTML, 'BR' équivaut à un saut de ligne entre des mots. En fait, l'élément est remplacé par une fin de ligne. Les versions ultérieures de CSS prendront peut-être en compte un contenu ajouté ou remplacé, dans l'immédiat les interpréteurs CSS1 doivent traiter 'BR' spécifiquement.

5 Les propriétés de CSS1

Les feuilles de style agissent sur la présentation des documents par assignation de valeurs aux propriétés de style. Ce chapitre dresse la liste des définitions de ces propriétés ainsi que les valeurs qui peuvent leur être associées selon CSS1.

5.1 La notation des valeurs de propriété

La liste des valeurs autorisées pour chaque propriété suit une syntaxe de ce genre :

Valeur : N | NW | NE
Valeur : [ <longueur> | thick | thin ]{1,4}
Valeur : [<nom de la famille> , ]* <nom de la famille>
Valeur : <url>? <couleur> [ / <couleur> ]?
Valeur : <url> || <couleur>

Les mots entre "<" et ">" indiquent le type de la valeur. Les plus communs sont <longueur>, <pourcentage>, <url>, <nombre> et <couleur> qui sont définis au chapitre 6. Ceux d'un type plus spécialisé (ex. <famille-nom> et <bordure-style>) sont décrits dans la propriété correspondante.

Les autres mots sont des mots-clés devant apparaître littéralement, sans guillemets, tout comme la barre oblique (/) et la virgule (,).

Si plusieurs items sont juxtaposés, alors tous doivent survenir dans l'ordre donné. La barre (|) sépare les choix possibles, cela signifie qu'un parmi ceux-ci doit être choisi. La double barre (A || B) signifie le choix de A ou B ou des deux, dans n'importe quel ordre. Les crochets ([ ]) servent au regroupement. La juxtaposition a un poids plus grand que la double barre, et la double barre que la barre simple. Ainsi "a b | c || d e" équivaut à "[ a b ] | [ c || [ d e ]]".

Chaque type, mot-clé ou groupe entre crochets peut être suivi par l'un des modificateurs suivants :

  • L'astérisque (*) signifie que ce qui précède se répète zéro ou plusieurs fois.
  • Le plus (+), ce qui précède se répète une ou plusieurs fois.
  • Le point d'interrogation (?), ce qui précède est facultatif.
  • Une paire de nombre dans des accolades ({A,B}), ce qui précède se répète au moins A fois et au plus B fois.

5.2 Les propriétés des polices

Agir sur les propriétés des polices est un des usages les plus communs des feuilles de style. Malheureusement, il n'existe pas de taxonomie bien définie et universellement reconnue pour classer les polices, les termes appropriés à une famille de police ne s'appliquent pas forcément à d'autres familles. Par exemple, 'italic' est souvent utilisé pour désigner un texte en italique, mais un texte en italique est aussi qualifié d'écriture Oblique, Penchée, Inclinée, Cursive voire Kursiv. Ce qui rend difficile la relation entre les propriétés typiques de la police sélectionnée et une police spécifique.

CSS1 définit les propriétés 'font-family', 'font-style', 'font-variant', 'font-weight', 'font-size' et 'font'.

5.2.1 L'ajustement des polices

Du fait d'une taxonomie des polices non universelle, l'ajustement des propriétés à l'aspect des polices requiert un soin particulier. Elles sont ajustées dans un ordre bien déterminé pour assurer un rendu aussi consistant que possible entre agents utilisateurs (en supposant que la même librairie de polices leur soit présentée).

  1. L'agent utilisateur construit (ou accède à) une base de données des propriétés concernées de CSS1 pour toutes les polices dont l'existence lui est connue. Une police peut être connue parce qu'elle est déjà installée localement ou parce qu'elle a été téléchargée du Web un peu plus tôt. Si deux polices ont exactement les mêmes caractéristiques, l'une d'elles est ignorée.
  2. L'agent utilisateur réunit les propriétés de texte qui s'applique à un élément donné et pour chaque caractère de cet élément. Celui-ci, à l'aide du jeu complet des propriétés, applique la propriété 'font-family' pour y choisir une police et l'essayer. Pour chacune des autres propriétés, une vérification de concordance est faite avec celle-ci. Si toutes les propriétés sont concordantes, cette police est retenue pour cet élément.
  3. Si cette précédente étape échoue à faire correspondre la police désignée par 'font-family' et une police disponible, alors cette étape est reconduite avec la police suivante spécifiée dans 'font-family' tant qu'il y en a une.
  4. Si une police est trouvée mais qu'un caractère ne dispose pas d'un glyphe dans celle-ci, on répète le processus de correspondance avec la police suivante désignée par 'font-family', s'il y en a une. Voir l'annexe C pour des renseignements sur les polices et le codage des caractères.
  5. Si aucune police ne correspond à la famille spécifiée par 'font-family', alors l'agent utilisateur recommence les tests à partir de ses propres polices par défaut jusqu'à trouver le meilleur compromis parmi celles-ci.

(Cet algorithme peut être amélioré en évitant de tester chaque caractère avec l'ensemble des propriétés CSS1).

Les tests de correspondance de l'étape 2 ci-dessus se fondent sur les règles suivantes :

  1. Le test sur 'font-style' est essayé en premier. La valeur 'italic' est retenue si la base de données des polices de l'agent utilisateur contient une police marquée avec les mots-clés 'italic' (préférable) ou bien 'oblique'. Autrement les valeurs doivent correspondre exactement sinon le test sur 'font-style' échoue.
  2. Puis vient le test sur 'font-variant'. La valeur 'normal' retient une police qui n'est pas marquée 'small-caps'. La valeur 'small-caps' retient (1) une police marquée 'small-caps' ou (2) une police dans laquelle les petites capitales sont synthétisées ou (3) une police dont toutes les minuscules sont remplacées par des capitales. On peut synthétiser électroniquement les petites capitales en jouant sur l'échelle des capitales d'une police normale.
  3. Le test sur 'font-weight' n'échoue jamais. (Voir 'font-weight' plus loin).
  4. Le résultat du test sur 'font-size' doit s'inscrire dans une marge de valeurs qui dépend de l'agent utilisateur (typiquement, la taille des polices variables est arrondie au pixel entier le plus proche alors que la tolérance sur la taille des polices fixes peut aller jusqu'à 20%). Les calculs supplémentaires (p.ex. sur les valeurs exprimées en 'em' pour les autres propriétés) se basent alors sur la valeur établie pour 'font-size' et non sur la valeur qui y est spécifiée.

5.2.2 'font-family'

Valeur : [[<famille-nom> | <famille-générique>],]* [<famille-nom> | <famille-générique>]
Valeur initiale : propre à l'agent
S'applique à : tous les éléments
Héritée : oui
Pourcentage : sans objet

Valeur représente une liste par ordre de priorité de noms de famille de polices et/ou de noms de famille génériques. Différence avec la plupart des autres propriétés CSS1, on sépare les valeurs avec une virgule pour montrer les choix possibles :

BODY { font-family: gill, helvetica, sans-serif }

On a deux types de liste de valeurs :

<famille-nom>
C'est le nom de la famille de police choisie. Dans l'exemple, "gill" et "helvetica" sont des familles de polices.
<famille-générique>
Toujours dans l'exemple, la dernière valeur est le nom d'une famille générique. Voici celles qui sont définies :
  • 'serif' (ex. Times)
  • 'sans-serif' (ex. Helvetica)
  • 'cursive' (ex. Zapf-Chancery)
  • 'fantasy' (ex. Western)
  • 'monospace' (ex. Courier)

On encourage les auteurs à proposer en dernier ressort une famille générique.

Si le nom d'une police contient un espace, on l'écrit entre guillemets :

BODY { font-family: "new century schoolbook", serif }

<BODY STYLE="font-family: 'Ma jolie police', fantasy">

Si on ne met pas les guillemets, les blancs situés avant et après le nom de la police sont ignorés et toute séquence de blancs à l'intérieur du nom se réduit à un seul.

5.2.3 'font-style'

Valeur : normal | italic | oblique
Valeur initiale : normal
S'applique à : tous les éléments
Héritée : oui
Pourcentage : sans objet

La propriété 'font-style' effectue une sélection entre les déclinaisons d'une police, soit normale (qu'on qualifie aussi de "romaine"), italique et oblique.

La valeur 'normal' sélectionne une police dans la base de données des polices de l'agent utilisateur classée 'normal', et 'oblique' une police marquée 'oblique'. La valeur 'italic' recherche une police marquée 'italic' ou, si non disponible, 'oblique'.

Une police marquée 'oblique' dans la base de données de l'agent utilisateur peut en fait être une police normale qui a été penchée électroniquement.

Les polices dont le nom contient "Oblique", "Slanted" ou "Incline" sont typiquement considérées comme 'oblique' dans la base de données de l'agent utilisateur et celles dont le nom contient "Italic", "Cursive" ou "Kursiv" comme 'italic'.

H1, H2, H3 { font-style: italic }
H1 EM { font-style: normal }

Dans cet exemple, le texte mis en exergue à l'intérieur de 'H1' prend un style normal.

5.2.4 'font-variant'

Valeur : normal | small-caps
Valeur initiale : normal
S'applique à : tous les éléments
Héritée : oui
Pourcentage : sans objet

Les petites capitales (N.D.T. small-caps) sont un autre genre de variation dans une famille de police. Les minuscules d'une police en petites capitales ressemblent aux capitales avec une taille réduite et des proportions légèrement différentes. La propriété 'font-variant' sélectionne une telle police.

La valeur 'normal' retient une police qui n'est pas en petites capitales et 'small-caps' une police en petites capitales. CSS1 tolère (mais n'impose pas) que les petites capitales soient créées à partir des majuscules d'une police normale. Les majuscules se substituent aux petites capitales en dernier ressort.

Cet exemple montre un élément 'H3' en petites capitales avec des mots mis en exergue en petites capitales italiques :

H3 { font-variant: small-caps }
EM { font-style: oblique }

D'autres variations sont possibles dans une famille de police, telles les polices avec des chiffres de style ancien, des chiffres en petites capitales, des lettres au style condensé ou étendu, etc. CSS1 n'a pas de propriétés pour cela.

CSS1 de base : dans la mesure où cette propriété change le texte en capitales, ces considérations sont aussi valables pour 'text-transform'.

5.2.5 'font-weight'

Valeur : normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900
Valeur initiale : normal
S'applique à : tous les éléments
Héritée : oui
Pourcentage : sans objet

La propriété 'font-weight' donne la graisse (N.D.T. weight) de la police. Les valeurs de '100' à '900' forment une séquence ordonnée où chacune indique une graisse au moins aussi noire que la précédente. Le mot-clé 'normal' équivaut à '400' et 'bold' à '700'. Les mots-clés autres que ces derniers étaient souvent confondus avec le nom des polices, c'est pourquoi une échelle numérique a été préférée pour cette liste de 9 valeurs.

P { font-weight: normal }   /* 400 */
H1 { font-weight: 700 }     /* bold */

Les valeurs 'bolder' et 'lighter' donnent un résultat relatif à la graisse héritée du parent :

STRONG { font-weight: bolder }

Les enfants héritent de la graisse résultante et non de la valeur du mot-clé.

Les polices (les données) ont typiquement une ou plusieurs propriétés dont le nom est révélateur de leur "graisse". Il n'existe pas de nomenclature universellement acceptée pour les dénominations des graisses. Elles servent principalement à distinguer les déclinaisons des graisses d'une même police. L'usage est très variable selon les familles de police. Vous pourriez par exemple considérer un texte écrit en gras alors qu'on le dit Regular, Roman, Book, Medium, Semi- ou DemiBold, Bold ou Black, dans la mise en page en fonction de la graisse de la police "normale". En l'absence d'une dénomination standard, CSS1 indique des valeurs pour la propriété de graisse sur une échelle graduée dans laquelle la valeur '400' ('normal') correspond au dessin de la police normale dans la famille. On associe couramment à celle-ci le nom de graisse Book, Regular, Roman, Normal ou parfois Medium.

Les autres valeurs de graisse disponibles dans l'échelle numérique ne sont présentes que pour conserver une certaine graduation de la graisse dans une famille de police. Voici quelques pistes qui montrent comment traiter certains cas typiques :

  • Si la famille de police utilise déjà une échelle de neuf valeurs (comme OpenType), les graisses devraient avoir une correspondance directe avec ces valeurs.
  • S'il existe à la fois une police marquée Medium et une marquée Book, Regular, Roman ou Normal, alors on fait correspondre la Medium à '500'.
  • La police marquée "Bold" correspond souvent à la valeur de graisse '700'.
  • S'il y a moins de 9 graisses dans la famille, un algorithme par défaut peut combler les "manques" comme ceci : si '500' n'a pas de police correspondante, on fait alors correspondre cette graisse à la même police qui correspond déjà à '400'. Si une parmi les valeurs '600', '700', '800' ou '900' n'a pas de police correspondante, alors cette valeur partage la même police correspondante, si elle existe, que celle du mot-clé 'bolder', ou sinon, que celle qui correspond à 'lighter'. Si une parmi les valeurs '300', '200' ou '100' n'a pas de correspondance, alors cette valeur partage la même correspondance, si elle existe, que celle du mot-clé 'lighter', ou sinon, que celle qui correspond à 'bolder'.

Les deux exemples suivants illustrent le processus. Supposons, allant du plus maigre au plus gras, que la famille "Exemple1" dispose des quatre graisses : Regular, Medium, Bold, Heavy. Et la famille "Exemple2" des six graisses : Book, Medium, Bold, Heavy, Black, ExtraBlack. Pour la famille "Exemple2", noter que "Exemple2 ExtraBlack" dans le deuxième exemple n'a pas de correspondance.

 Polices disponibles  | Corresp.     |  En comblant
----------------------+--------------+-------------------
"Exemple1 Regular"    | 400          |  100, 200, 300
"Exemple1 Medium"     | 500          |
"Exemple1 Bold"       | 700          |  600
"Exemple1 Heavy"      | 800          |  900

 Polices disponibles  | Corresp.     |  En comblant
----------------------+--------------+-------------------
"Example2 Book"       | 400          |  100, 200, 300
"Example2 Medium"     | 500          |
"Example2 Bold"       | 700          |  600
"Example2 Heavy"      | 800          |
"Example2 Black"      | 900          |
"Example2 ExtraBlack" | (...)        |

L'action des mots-clés relatifs 'bolder' et 'lighter' a pour effet de d'épaissir ou d'amaigrir une police dans une même famille. Quand une famille n'a pas de correspondant pour chacune des valeurs de graisse numériques, 'bolder' va être assigné à la police de graisse supérieure disponible pour l'agent utilisateur, et 'lighter' à la police de graisse inférieure. Suit la signification précise des mots-clés relatifs 'bolder' et 'lighter' :

  • 'bolder' prend la valeur de la graisse supérieure à celle qui est spécifiée. S'il manque la police correspondante, sa valeur prend simplement celle au-dessus dans l'échelle numérique (et la police ne change pas d'aspect), à moins que cette valeur ne soit déjà à '900', valeur qui, auquel cas, est conservée.
  • 'lighter' fonctionne de la même façon dans le sens inverse. La sélection se porte sur la police de graisse inférieure à celle qui est spécifiée, et, s'il manque la police correspondante, elle se fait sur la valeur numérique inférieure dans l'échelle (et la police ne change pas d'aspect).

L'existence d'une graisse plus épaisse pour toutes les valeurs de 'font-weight' n'est pas garantie. Par exemple, certaines familles de police n'ont que les graisses normale et grasse, d'autres peuvent avoir huit neuf graisses différentes. On ne sait jamais comment un agent utilisateur va faire correspondre les polices d'une famille avec les valeurs de graisse. La seule garantie est qu'une police pour une valeur de graisse donnée ne sera pas moins grasse qu'une police de valeur de graisse moindre.

5.2.6 'font-size'

Valeur : <taille absolue> | <taille relative> | <longueur> | <pourcentage>
Valeur initiale : medium
S'applique à : tous les éléments
Héritée : oui
Pourcentage : relatif à la taille de police du parent

<taille absolue>
Le mot-clé <taille absolue> est un index pointant sur la table des tailles de police qui est calculée et maintenue par l'agent utilisateur. Les valeurs possibles : [ xx-small | x-small | small | medium | large | x-large | xx-large ]. Pour un écran d'ordinateur, il est suggéré un facteur d'échelle de 1.5 entre deux index adjacents ; si pour 'medium' la taille de la police fait 10pt, pour 'large', elle fait 15pt. Ce facteur nécessite sûrement une adaption aux différents médias. L'agent utilisateur peut aussi considérer la qualité et la disponibilité des polices au moment de dresser cette table. Cette table peut être différente d'une famille de police à l'autre.
<taille relative>
Le mot-clé <taille relative> s'entend relatif à la table des tailles de police et à la taille de police du parent. Les valeurs possibles sont : [ larger | smaller ]. Par exemple, admettons que le parent ait une taille de police 'medium', la valeur 'larger' fera passer la taille de police de l'enfant à 'large'. Si la taille de la police du parent est trop éloignée d'une des entrées de la table, l'agent utilisateur est libre d'interpoler entre différentes entrées ou d'arrondir au plus proche. Il peut y être contraint si les mots-clés provoquent une sortie du champs de valeur de la table.

Les valeurs de longueur et de pourcentage ne devraient pas dépendre de la table des tailles de police pour le calcul de la taille de police d'un élément.

Les valeurs négatives sont interdites.

Pour toutes les autres propriétés, les valeurs en 'em' et 'ex' dépendent de la taille de police de l'élément même. Pour la propriété 'font-size', ces unités de longueur se réfèrent à la taille de police de l'élément parent.

Noter qu'une application peut redéfinir une taille explicite selon le contexte. Exemple, une scène en Réalité Virtuelle où la taille de la police peut varier avec la perspective.

Exemples :

P { font-size: 12pt; }
BLOCKQUOTE { font-size: larger }
EM { font-size: 150% }
EM { font-size: 1.5em }

Avec le facteur d'échelle 1.5 suggéré, les trois dernières déclarations sont identiques.

5.2.7 'font'

Valeur : [ <font-style> || <font-variant> || <font-weight> ]? <font-size> [ / <line-height> ]? <font-family>
Valeur initiale : non défini pour les propriétés génériques
S'applique à : tous les éléments
Héritée : oui
Pourcentage : admis sur <font-size> et <line-height>

La propriété générique 'font' est un raccourci pour regrouper 'font-style' 'font-variant' 'font-weight' 'font-size', 'line-height' et 'font-family' dans la feuille de style. Sa syntaxe est basée sur une notation traditionnelle écourtée dans le but d'adresser plusieurs propriétés liées aux polices.

Pour leurs valeurs admises et leur valeur initiale, voir les propriétés déjà définies. Les propriétés dont aucune valeur n'apparaît prennent leur valeur initiale.

P { font: 12pt/14pt sans-serif }
P { font: 80% sans-serif }
P { font: x-large/110% "new century schoolbook", serif }
P { font: bold italic large Palatino, serif }
P { font: normal small-caps 120%/120% fantasy }

Dans la deuxième règle, la valeur exprimée en pourcentage se réfère à la taille de la police de l'élément parent. Dans la troisième règle, la hauteur de ligne exprimée en pourcentage se réfère à la taille de police de l'élément lui-même.

Dans les trois premières règles, les propriétés 'font-style', 'font-variant' et 'font-weight' ne sont pas mentionnées explicitement, cela signifie qu'elles gardent leur valeur initiale ('normal'). La quatrième règle spécifie implicitement les valeurs 'bold' pour 'font-weight', 'italic' pour 'font-style' et 'normal' pour 'font-variant'.

La cinquième règle fixe les valeurs des propriétés 'font-variant' ('small-caps'), 'font-size' (120% du parent), 'line-height' (120% de la taille de la police) et 'font-family' ('fantasy'). Leur valeur initiale qui est 'normal' est donc appliquée aux deux propriétés restantes, 'font-style' et 'font-weight'.

5.3 Les propriétés de couleur et de fond

Ces propriétés décrivent la couleur (souvent appelé couleur de premier plan) et le fond d'un élément (c.-à-d., la surface sur laquelle le contenu est rendu). On peut donner une couleur et/ou une image au fond. On peut aussi préciser la position de cette image, si elle doit se répéter et comment, et dire si elle doit rester fixe ou défiler avec le canevas.

La propriété 'color' s'hérite normalement. Les propriétés de fond n'héritent pas, cependant le fond du parent sera visible par défaut car la propriété 'background-color' a pour valeur initiale 'transparent'.

5.3.1 'color'

Valeur : <couleur>
Valeur initiale : selon l'agent
S'applique à : tous les éléments
Héritée : oui
Pourcentage : sans objet

Cette propriété décrit la couleur du texte d'un élément. On peut spécifier la couleur rouge de plusieurs façons :

EM { color: red }              /* langage naturel */
EM { color: rgb(255,0,0) }     /* valeurs RGB de 0 à 255 */

Voir au chapitre 6.3 pour les valeurs de couleur possibles.

5.3.2 'background-color'

Valeur : <couleur> | transparent
Valeur initiale : transparent
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété fixe la couleur du fond d'un élément.

H1 { background-color: #F00 }

5.3.3 'background-image'

Valeur : <url> | none
Valeur initiale : none
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété précise l'image de fond d'un élément. Quand on a une image de fond, il est aussi souhaitable de donner une couleur de fond qui reste visible quand l'image n'est pas disponible. Celle ci s'affiche par dessus la couleur de fond dès qu'elle est disponible.

BODY { background-image: url(marble.gif) }
P { background-image: none }

5.3.4 'background-repeat'

Valeur : repeat | repeat-x | repeat-y | no-repeat
Valeur initiale : repeat
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Quand on a une image de fond, la propriété 'background-repeat' détermine si l'image doit se répéter et le cas échéant la manière dont elle se répète.

L'image est répétée à la fois dans les sens horizontal et vertical pour la valeur 'repeat', dans le sens horizontal pour la valeur 'repeat-x', ce qui produit une bande d'images d'un bord à l'autre. Idem pour 'repeat-y' dans le sens vertical. La valeur 'no-repeat' supprime toute répétition.

BODY {
  background: red url(pendant.gif);
  background-repeat: repeat-y;
}

Ici, l'image est répétée verticalement.

5.3.5 'background-attachment'

Valeur : scroll | fixed
Valeur initiale : scroll
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Si on a une image de fond, la valeur de 'background-attachment' détermine si celle-ci est fixe par rapport au canevas ('fixed') ou si elle défile en même temps que le contenu ('scroll').

BODY {
  background: red url(pendant.gif);
  background-repeat: repeat-y;
  background-attachment: fixed;
}

CSS1 de base : L'agent utilisateur peut substituer la valeur 'scroll' à 'fixed'. Néanmoins, 'fixed' doit être interprété correctement, au moins pour les éléments 'HTML' et 'BODY', l'auteur n'ayant aucun moyen de fournir une image uniquement aux navigateurs comprenant cette valeur. (Cf. chapitre 7).

5.3.6 'background-position'

Valeur : [<pourcentage> | <longueur>]{1,2} | [top | center | bottom] || [left | center | right]
Valeur initiale : 0% 0%
S'applique à : ceux des éléments de type bloc et remplacés
Héritée : non
Pourcentage : relatif à la taille de l'élément lui-même

Si on a une image de fond, la valeur de 'background-position' en précise la position initiale.

Avec la paire de valeur '0% 0%', le coin en haut à gauche de l'image est aligné sur celui de la boîte qui entoure le contenu de l'élément (pas la boîte qui englobe l'espacement, la bordure et la marge). La paire de valeur '100% 100%' positionne le coin en bas à droite de l'image sur celui de l'élément. Avec la paire de valeur '14% 84%', le point situé 14% vers la droite et 84% vers le bas dans l'image est placé sur le point situé 14% vers la droite et 84% vers le bas dans l'élément.

Avec la paire de valeur '2cm 2cm', le coin en haut à gauche de l'image est placé 2cm vers la droite et 2cm sous le coin en haut à gauche de l'élément.

Si une seule valeur de pourcentage ou de longueur est fournie, celle-ci ne donne que la position horizontale, la position verticale sera 50%. Si on fournit deux valeurs, la première est la position horizontale. Les combinaisons de valeurs exprimées en longueur et en pourcentage sont admises, ex. '50% 2cm'. Les positions négatives ne le sont pas.

On peut aussi utiliser des mots-clés pour indiquer la position de l'image de fond. Les combinaisons avec des mots-clés et des valeurs en pourcentage ou longueur ne sont pas permises. Voici les combinaisons possibles de mots-clés et leurs interprétations :

  • 'top left' et 'left top' <==> '0% 0%'.
  • 'top', 'top center' et 'center top' <==> '50% 0%'.
  • 'right top' et 'top right' <==> '100% 0%'.
  • 'left', 'left center' et 'center left' <==> '0% 50%'.
  • 'center' et 'center center' <==> '50% 50%'.
  • 'right', 'right center' et 'center right' <==> '100% 50%'.
  • 'bottom left' et 'left bottom' <==> '0% 100%'.
  • 'bottom', 'bottom center' et 'center bottom' <==> '50% 100%'.
  • 'bottom right' et 'right bottom' <==> '100% 100%'.

Exemples :

BODY { background: url(banner.jpeg) right top }    /* 100%   0% */
BODY { background: url(banner.jpeg) top center }   /*  50%   0% */
BODY { background: url(banner.jpeg) center }       /*  50%  50% */
BODY { background: url(banner.jpeg) bottom }       /*  50% 100% */

Si l'image de fond est fixe par rapport au canevas (cf. 'background-attachment' plus haut), l'image se place relativement à celui-ci et non à l'élément. Exemple :

BODY {
  background-image: url(logo.png);
  background-attachment: fixed;
  background-position: 100% 100%;
}

Ici, l'image bute dans le coin en bas à droite du canevas.

5.3.7 'background'

Valeur : <background-color> || <background-image> || <background-repeat> || <background-attachment> || <background-position>
Valeur initiale : non définie pour les propriétés génériques
S'applique à : tous les éléments
Héritée : non
Pourcentage : admis pour <background-position>

La propriété générique 'background' est un raccourci pour regrouper les propriétés de fond individuelles ('background-color', 'background-image', 'background-repeat', 'background-attachment' et 'background-position') dans la feuille de style.

Les valeurs de la propriété 'background' sont formées d'un jeu des valeurs possibles pour ces propriétés individuelles.

BODY { background: red }
P { background: url(chess.png) gray 50% repeat fixed }

La propriété 'background' fixe toutes les propriétés de fond individuelles. Dans l'exemple ci-dessus, la première règle spécifie juste une valeur pour 'background-color', les valeurs initiales des autres propriétés individuelles sont implicites. Dans la seconde règle, les valeurs sont spécifiées pour chacune des propriétés individuelles.

5.4 Les propriétés du texte

5.4.1 'word-spacing'

Valeur : normal | <longueur>
Valeur initiale : normal
S'applique à : tous les éléments
Héritée : oui
Pourcentage : sans objet

La valeur indiquée par <longueur> s'ajoute à celle de l'espace normal entre les mots. Cette valeur peut être négative, mais son interprétation s'inscrira dans des limites spécifiques à l'agent utilisateur. Celui-ci est libre de calculer l'espace exact. L'espace-mot (N.D.T. word-spacing) peut aussi subir l'influence de la justification (qui est une valeur de la propriété 'text-align').

H1 { word-spacing: 1em }

Ici, l'espace-mot des éléments 'H1' est augmenté de 1em.

CSS1 de base : L'agent utilisateur peut substituer la valeur de longueur de 'word-spacing' par 'normal'. Cf. chapitre 7.

5.4.2 'letter-spacing'

Valeur : normal | <longueur>
Valeur initiale : normal
S'applique à : tous les éléments
Héritée : oui
Pourcentage : sans objet

La valeur indiquée par <longueur> s'ajoute à l'interlettrage par défaut. Cette valeur peut être négative, mais son interprétation s'inscrira dans des limites spécifiques à l'agent utilisateur. L'agent utilisateur est libre de calculer l'espace exact. L'interlettrage peut subir l'influence de la justification (une des valeurs de la propriété 'text-align').

BLOCKQUOTE { letter-spacing: 0.1em }

Ici, l'interlettrage des éléments 'BLOCKQUOTE' est augmenté de 0.1em.

La valeur 'normal' autorise l'agent utilisateur à modifier l'interlettrage pour la justification du texte. Si 'letter-spacing' a une valeur de longueur, ce n'est plus le cas :

BLOCKQUOTE { letter-spacing: 0 }
BLOCKQUOTE { letter-spacing: 0cm }

L'agent utilisateur ne peut utiliser de ligatures si l'interlettrage a été modifié.

CSS1 de base : L'agent utilisateur peut interpréter une valeur de longueur de 'letter-spacing' par 'normal'. Cf. chapitre 7.

5.4.3 'text-decoration'

Valeur : none | [ underline || overline || line-through || blink ]
Valeur initiale : none
S'applique à : tous les éléments
Héritée : non, voir explication plus bas
Pourcentage : sans objet

Cette propriété décrit les décorations ajoutées au texte d'un élément. Elle n'a aucun effet sur les éléments dépourvus de texte (ex. 'IMG' en HTML) ou sur les éléments vides (ex. '<EM></EM>'). La valeur 'blink' fait clignoter le texte.

La(les) couleur(s) requise(s) pour la décoration devrai(en)t être issue(s) de la valeur de la propriété 'color'.

La propriété ne s'hérite pas, cependant les éléments doivent tenir de leur parent. Un exemple, les enfants d'un élément souligné devraient aussi l'être. La couleur de soulignage doit se perpétuer même si les descendants ont d'autres valeurs pour 'color'.

A:link, A:visited, A:active { text-decoration: underline }

Dans l'exemple, le texte de tous les liens (les éléments 'A' avec un attribut 'HREF') est souligné.

Les agents utilisateurs doivent reconnaître le mot-clé 'blink' mais ne sont pas tenus d'en réaliser l'effet.

5.4.4 'vertical-align'

Valeur : baseline | sub | super | top | text-top | middle | bottom | text-bottom | <percentage>
Valeur initiale : baseline
S'applique à : les éléments en-ligne
Héritée : non
Pourcentage : selon la valeur de 'line-height' de l'élément lui-même

La propriété agit sur le positionnement vertical de l'élément. Un jeu de mots-clés est relatif à l'élément parent :

'baseline'
aligne la ligne de base d'un élément (ou le bas, si l'élément n'a pas de ligne de base) sur celle de son parent.
'middle'
aligne le milieu vertical d'un élément (en général une image) sur le milieu vertical de l'élément parent, c.à.d., sa ligne de base relevée de la moitié de sa hauteur.
met l'élément en indice.
'sub'
met l'élément en indice.
'super'
met l'élément en exposant.
'text-top'
aligne le sommet d'un élément avec celui du texte du parent.
'text-bottom'
aligne le bas d'un élément avec le bas du texte du parent.

Un autre jeu est relatif à la ligne dont fait partie l'élément :

'top'
aligne le sommet de l'élément avec celui de l'élément le plus haut dans la ligne.
'bottom'
aligne le bas de l'élément avec celui de l'élément le plus bas dans la ligne.

L'utilisation conjointe de 'top' et 'bottom' peuvent conduire à des situations sans issues en cas de références circulaires.

Les valeurs en pourcentage se réfèrent à la valeur de la propriété 'line-height' de l'élément en question. Ces valeurs montent la ligne de base de élément (ou le bas, s'il n'en a pas) au-dessus de celle du parent de la quantité déterminée. Les valeurs négatives sont admises. Par exemple, une valeur de '-100%' abaisse l'élément de telle manière que sa ligne de base prend la place de celle de la ligne suivante. Ceci permet un contrôle précis du positionnement vertical des éléments qui n'ont pas de ligne de base (comme avec l'utilisation d'images en lieu de texte).

Une version ultérieure de CSS autorisera sans doute les valeurs de <longueur> pour cette propriété.

5.4.5 'text-transform'

Valeur : capitalize | uppercase | lowercase | none
Valeur initiale : none
S'applique à : tous les éléments
Héritée : oui
Pourcentage : sans objet

'capitalize'
met la première lettre de chaque mot en majuscule
'uppercase'
met en majuscule toutes les lettres de l'élément
'lowercase'
met en minuscule toutes les lettres de l'élément
'none'
neutralise la valeur héritée.

Dans chaque cas, la transformation effectuée dépend de la langue. Voir en [4] la façon de déterminer la langue pour un élément.

H1 { text-transform: uppercase }

Le contenu de 'H1' est en majuscule.

CSS1 de base : Les agents utilisateurs peuvent ignorer 'text-transform' et le traiter comme 'none' pour les caractères qui ne font pas partie du répertoire Latin-1 ou pour les éléments avec des langues dont la transformation serait différente par rapport à celle prévue dans les tables de conversion Unicode [8].

5.4.6 'text-align'

Valeur : left | right | center | justify
Valeur initiale : selon l'agent utilisateur
S'applique à : ceux des éléments de type bloc
Héritée : oui
Pourcentage : sans objet

Cette propriété décrit l'alignement du texte d'un élément. L'algorithme de justification appliqué dépend de l'agent utilisateur et de la langue.

Exemple :

DIV.center { text-align: center }

Comme la propriété 'text-align' est héritée, toutes les boîtes de ligne de tous les sous-éléments de type bloc de 'DIV' dont la classe est 'center' sont centrés. Noter que l'alignement est appliqué relativement à la largeur de l'élément et non au canevas. L'agent utilisateur doit remplacer la valeur 'justify' s'il ne reconnaît pas celle-ci. C'est en général 'left' pour les langues occidentales.

CSS1 de base : L'agent utilisateur peut interpréter 'justify' respectivement comme 'left' ou 'right' selon que le sens d'écriture est de la gauche vers la droite ou de la droite vers la gauche.

5.4.7 'text-indent'

Valeur : <longueur> | <pourcentage>
Valeur initiale : 0
S'applique à : ceux des éléments de type bloc
Héritée : oui
Pourcentage : relatif à la largeur du parent

La propriété spécifie l'alinéa (N.D.T. indent) appliqué sur la première ligne formatée. La valeur de 'text-indent peut être négative, mais son interprétation est soumise aux limites de tel ou tel agent utilisateur. L'alinéa ne peut apparaître au milieu d'un élément coupé par un autre (ainsi 'BR' en HTML).

Exemple:

P { text-indent: 3em }

5.4.8 'line-height'

Valeur : normal | <nombre> | <longueur> | <pourcentage>
Valeur initiale : normal
S'applique à : tous les éléments
Héritée : oui
Pourcentage : relatif à la taille de la police de l'élément lui-même

Cette propriété fixe l'écart entre les lignes de base de deux lignes adjacentes.

Si on spécifie une valeur numérique, la hauteur de ligne est obtenue en multipliant la taille de police de l'élément en question avec cette valeur-là. Ce qui est différent d'une valeur en pourcentage qui est héritée car les enfants héritent de la valeur numérique elle-même et non pas de la valeur résultante (comme c'est le cas pour le pourcentage et d'autres unités).

On n'admet pas de valeurs négatives.

Les trois règles suivantes donnent une même hauteur de ligne :

DIV { line-height: 1.2; font-size: 10pt }     /* nombre */
DIV { line-height: 1.2em; font-size: 10pt }   /* longueur */
DIV { line-height: 120%; font-size: 10pt }    /* pourcentage */

La valeur 'normal' met la hauteur de ligne dans un rapport raisonnable avec la police de l'élément. De préférence, l'agent utilisateur établit une valeur dans un rapport de 1.0 à 1.2.

Voir le chapitre 4.4 pour une description de l'influence de 'line-height' sur le format d'un élément de type bloc.

5.5 Propriétés de boîte

Ces propriétés fixent la taille, les contours et la position des boîtes qui représentent les éléments. Voir le modèle de mise en forme (chapitre 4) pour des exemples d'application.

Les propriétés de marge spécifient les marges d'un élément. La propriété 'margin' fixe les marges sur les quatre bords, les propriétés de marge spécifiques fixent leur côté respectif.

Les propriétés d'espacement spécifient l'espace entre la bordure et le contenu (ex. texte ou image). La propriété 'padding' fixe l'espacement sur les quatre bords, les propriétés d'espacement spécifiques de leur côté respectif.

Les propriétés de bordure spécifient les bordures d'un propriété. Chaque élément possède quatre bordures définies par leur largeur, couleur et style.

Les propriétés 'width' et 'height' spécifient la taille de la boîte. Les propriétés 'float' et 'clear' peuvent modifier la position des éléments.

5.5.1 'margin-top'

Valeur : <longueur> | <pourcentage> | auto
Valeur initiale : 0
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

Cette propriété concerne la marge du haut d'un élément :

H1 { margin-top: 2em }

On admet une valeur négative, mais son interprétation est soumise aux limites de l'agent utilisateur.

5.5.2 'margin-right'

Valeur : <longueur> | <pourcentage> | auto
Valeur initiale : 0
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

Cette propriété concerne la marge de droite d'un élément :

H1 { margin-right: 12.3% }

On admet une valeur négative, mais son interprétation est soumise aux limites de l'agent utilisateur.

5.5.3 'margin-bottom'

Valeur : <longueur> | <pourcentage> | auto
Valeur initiale : 0
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

Cette propriété concerne la marge du bas d'un élément :

H1 { margin-bottom: 3px }

On admet une valeur négative, mais son interprétation est soumise aux limites de l'agent utilisateur.

5.5.4 'margin-left'

Valeur : <longueur> | <pourcentage> | auto
Valeur initiale : 0
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

Cette propriété concerne la marge de gauche d'un élément :

H1 { margin-left: 2em }

On admet une valeur négative, mais son interprétation est soumise aux limites de l'agent utilisateur.

5.5.5 'margin'

Valeur : [ <longueur> | <pourcentage> | auto ]{1,4}
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

La propriété 'margin' est un raccourci pour fixer et regrouper les propriétés 'margin-top', 'margin-right', 'margin-bottom' et 'margin-left' dans la feuille de style.

Si on spécifie quatre valeurs de longueur, celles-ci correspondent respectivement aux marges haute, droite, basse et gauche. Si on ne spécifie qu'une valeur, elle s'applique aux quatre côtés et s'il y en a deux ou trois, on déduit les valeurs manquantes de celles des côtés opposés.

BODY { margin: 2em }         /* toutes les marges ont 2em */
BODY { margin: 1em 2em }     /* haut et bas = 1em, droite et gauche = 2em */
BODY { margin: 1em 2em 3em } /* haut = 1em, droite = 2em, bas = 3em, gauche = 2em */

La dernière règle de cet exemple est équivalente à :

BODY {
  margin-top: 1em;
  margin-right: 2em;
  margin-bottom: 3em;
  margin-left: 2em;    /* pris du côté opposé (droit) */
}

On admet les valeurs négatives, mais leur interprétation est soumise aux limites de l'agent utilisateur.

5.5.6 'padding-top'

Valeur : <longueur> | <pourcentage>
Valeur initiale : 0
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

Cette propriété concerne l'espacement du haut d'un élément.

BLOCKQUOTE { padding-top: 0.3em }

Les valeurs d'espacement ne sont jamais négatives.

5.5.7 'padding-right'

Valeur : <longueur> | <pourcentage>
Valeur initiale : 0
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

Cette propriété concerne l'espacement de droite d'un élément.

BLOCKQUOTE { padding-right: 10px }

Les valeurs d'espacement ne sont jamais négatives.

5.5.8 'padding-bottom'

Valeur : <longueur> | <pourcentage>
Valeur initiale : 0
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

Cette propriété concerne l'espacement du bas d'un élément.

BLOCKQUOTE { padding-bottom: 2em }

Les valeurs d'espacement ne sont jamais négatives.

5.5.9 'padding-left'

Valeur : <longueur> | <pourcentage>
Valeur initiale : 0
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

Cette propriété concerne l'espacement de gauche d'un élément.

BLOCKQUOTE { padding-left: 20% }

Les valeurs d'espacement ne sont jamais négatives.

5.5.10 'padding'

Valeur : [ <longueur> | <pourcentage> ]{1,4}
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : tous les éléments
Héritée : non
Pourcentage : relatif à la dimension du parent de type bloc le plus proche

La propriété 'padding' est un raccourci pour fixer et regrouper les propriétés 'padding-top', 'padding-right', 'padding-bottom' et 'padding-left' dans la feuille de style.

Si on spécifie quatre valeurs de longueur, celles-ci correspondent respectivement aux espacements haut, droit, bas et gauche. Si on ne spécifie qu'une valeur, elle s'applique aux quatre côtés et s'il y en a deux ou trois, on déduit les valeurs manquantes de celles des côtés opposés.

Le fond de la surface d'espacement est spécifié par la propriété 'background' :

H1 {
  background: white;
  padding: 1em 2em;
}

Cet exemple montre un espacement vertical de 1em ('padding-top' et 'padding-bottom') et un espacement horizontal de 2em ('padding-right' et 'padding-left'). L'unité 'em' est relative à la taille de la police de l'élément, ainsi '1em' correspond à la taille de cette police.

Les valeurs d'espacement ne sont jamais négatives.

5.5.11 'border-top-width'

Valeur : thin | medium | thick | <longueur>
Valeur initiale : 'medium'
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété spécifie l'épaisseur de la bordure du haut d'un élément. La dimension donnée par les mots-clés dépend de l'agent utilisateur, mais ceci est toujours vérifié : 'thin' <= 'medium' <= 'thick'.

Les valeurs issues des mots-clés sont constantes pour un document :

H1 { border: solid thick red }
P  { border: solid thick blue }

Ici, les éléments 'H1' et 'P' ont une mème épaisseur indépendamment de la taille de la police. On peut obtenir des dimensions relatives en utilisant l'unité 'em' :

H1 { border: solid 0.5em }

Les bordures n'ont pas de valeurs négatives.

5.5.12 'border-right-width'

Valeur : thin | medium | thick | <longueur>
Valeur initiale : 'medium'
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété spécifie l'épaisseur de la bordure de droite d'un élément. Sinon, elle équivaut à 'border-top-width'.

5.5.13 'border-bottom-width'

Valeur : thin | medium | thick | <length>
Valeur initiale : 'medium'
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété spécifie l'épaisseur de la bordure du bas d'un élément. Sinon, elle équivaut à 'border-top-width'.

5.5.14 'border-left-width'

Valeur : thin | medium | thick | <length>
Valeur initiale : 'medium'
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété spécifie l'épaisseur de la bordure de gauche d'un élément. Sinon, elle équivaut à 'border-top-width'.

5.5.15 'border-width'

Valeur : [thin | medium | thick | <longueur>]{1,4}
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : tous les éléments
Pourcentage : sans objet

Cette propriété est un raccourci pour fixer et regrouper 'border-width-top', 'border-width-right', 'border-width-bottom' et 'border-width-left' 'border-top-width', 'border-right-width', 'border-bottom-width' et 'border-left-width' dans la feuille de style.

Elle se compose d'une à quatre valeurs qu'on interprète ainsi :

  • une valeur : les quatre bordures ont la mème épaisseur
  • deux valeurs : la première valeur est attribuée aux bordures du haut et du bas, la deuxième valeur à celles de droite et de gauche
  • trois valeurs : la première pour le haut, la deuxième pour la droite et la gauche la troisième pour le bas
  • quatre valeurs : le haut, la droite, le bas et la gauche respectivement.

Dans cet exemple, les commentaires indique les valeurs attribuées dans l'ordre haut, droite, bas et gauche :

H1 { border-width: thin }                   /* thin thin thin thin */
H1 { border-width: thin thick }             /* thin thick thin thick */
H1 { border-width: thin thick medium }      /* thin thick medium thin thick */
H1 { border-width: thin thick medium thin } /* thin thick medium thin */

Les bordures n'ont pas de valeurs négatives.

5.5.16 'border-color'

Valeur : <couleur>{1,4}
Valeur initiale : la valeur de la propriété 'color'
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

La propriété 'border-color' spécifie la couleur des quatres bordures. Elle se compose d'une à quatre valeurs de la même façon que pour 'border-width' au-dessus.

Si on ne spécifie aucune couleur, 'border-color' prend la valeur de la propriété 'color' de l'élément lui-même :

P {
  color: black;
  background: white;
  border: solid;
}

Ici, la bordure forme un cadre noir.

5.5.17 'border-style'

Valeur : [none | dotted | dashed | solid | double | groove | ridge | inset | outset]{1,4}
Valeur initiale : none
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

La propriété 'border-color' spécifie le style des quatre bordures. Elle se compose d'une à quatre valeurs de la même façon que pour 'border-width' au-dessus.

#xy34 { border-style: solid dotted }

Ici, les bordures horizontales sont en trait plein et les verticales en trait pointillé.

La valeur initiale de la propriété étant 'none', les bordures sont invisibles tant qu'aucune autre valeur n'est spécifiée.

Les valeurs de style de bordure signifient :

none
aucune bordure n'apparaît (indépendamment de la valeur de 'border-width')
dotted
la bordure est une ligne pointillée tracée sur le fond de l'élément
dashed
la bordure est une ligne en tirets tracée sur le fond de l'élément
solid
la bordure est un trait plein
double
la bordure est un trait double tracé sur le fond de l'élément. La somme des épaisseurs des deux traits simples et de l'espace entre eux est égale à la valeur de <border-width>
groove
une cannelure en 3D est dessinée d'après la valeur de <color>.
ridge
une strie en 3D est dessinée d'après la valeur de <color>.
inset
une incrustation en 3D est dessinée d'après la valeur de <color>.
outset
une extrusion en 3D est dessinée d'après la valeur de <color>.

CSS1 de base : L'agent utilisateur peut interpréter 'dotted', 'dashed', 'double', 'groove', 'ridge', 'inset' et 'outset' comme un trait plein ('solid').

5.5.18 'border-top'

Valeur : <border-top-width> || <border-style> || <couleur>
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété est un raccourci pour spécifier l'épaisseur, le style et la couleur de la bordure du haut d'un élément.

H1 { border-top: thick solid red }

La règle ci-dessus indique l'épaisseur, le style et la couleur de la bordure au-dessus de 'H1'. Les valeurs omises prennent leur valeur initiale :

H1 { border-top: thick solid }

Comme ici la valeur de la couleur est omise, la bordure prend la valeur de 'color' de l'élément lui-même.

Noter que cette propriété n'a qu'une seule valeur de style alors que 'border-style' en accepte jusqu'à quatre.

5.5.19 'border-right'

Valeur : <border-right-width> || <border-style> || <couleur>
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété est un raccourci pour spécifier l'épaisseur, le style et la couleur de la bordure de droite d'un élément. Sinon, elle équivaut à 'border-top'.

5.5.20 'border-bottom'

Value: <border-bottom-width> || <border-style> || <color>
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété est un raccourci pour spécifier l'épaisseur, le style et la couleur de la bordure du bas d'un élément. Sinon, elle équivaut à 'border-top'.

5.5.21 'border-left'

Valeur : <border-left-width> || <border-style> || <couleur>
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété est un raccourci pour spécifier l'épaisseur, le style et la couleur de la bordure de gauche d'un élément. Sinon, elle équivaut à 'border-top'.

5.5.22 'border'

Valeur : <border-width> || <border-style> || <couleur>
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : tous les éléments
Pourcentage : sans objet

La propriété 'border' est un raccourci pour donner la même valeur d'épaisseur, de couleur et de style aux quatre bordures d'un élément. Ainsi dans l'exemple, la première règle produit le même effet que le jeu de quatre règles qui la suit :

P { border: solid red }
P {
  border-top: solid red;
  border-right: solid red;
  border-bottom: solid red;
  border-left: solid red
}

À l'inverse des propriétés raccourcies 'margin' et 'padding', 'border' ne peut pas donner des valeurs différentes aux quatre bordures. Pour ce faire, il faut utiliser une ou plusieurs des autres propriétés de bordure.

Les fonctions de ces propriétés peuvent se recouper, aussi l'ordre d'écriture des règles devient important. Considérons ce qui suit :

BLOCKQUOTE {
  border-color: red;
  border-left: double;
  color: black;
}

Dans cet exemple, la bordure gauche est noire tandis que les autres sont rouges. C'est le fait de 'border-left', la valeur de la couleur n'étant pas spécifiée, qui va prendre la valeur de la propriété 'color'. Le fait que cette dernière soit fixée après la propriété 'border-left' ne fait pas de différence.

La propriété 'border' n'accepte qu'une seule valeur, bien que 'border-width' puisse en avoir jusqu'à quatre.

5.5.23 'width'

Valeur : <longueur> | <pourcentage> | auto
Valeur initiale : auto
S'applique à : ceux des éléments de type bloc et remplacés
Héritée : non
Pourcentage : relatif à la largeur du parent

On peut appliquer cette propriété au texte, elle est cependant bien plus utile avec les éléments remplacés comme les images. Si nécessaire, on peut contraindre la largeur d'une image. Dans un changement d'échelle, le ratio de l'image rendue est conservé si la propriété 'height' a la valeur 'auto'.

Exemple :

IMG.icon { width: 100px }

Pour un élément remplacé, les dimensions intrinsèques de l'objet qui le remplace sont assignées aux propriétés 'width' et 'height' si leur valeur initiale était 'auto'.

Les valeurs négatives ne sont pas admises.

Voir le modèle de mise en forme (chapitre 4) pour les relations existants entre cette propriété et la marge et l'espacement.

5.5.24 'height'

Valeur : <longueur> | auto
Valeur initiale : auto
S'applique à : ceux des éléments de type bloc et remplacés
Héritée : non
Pourcentage : sans objet

On peut appliquer cette propriété au texte, elle est cependant bien plus utile avec les éléments remplacés comme les images. Si nécessaire, on peut contraindre la hauteur d'une image. Dans un changement d'échelle, le ratio de l'image rendue est conservé si la propriété 'width' a la valeur 'auto'.

Exemple :

IMG.icon { height: 100px }

Quand les valeurs des propriétés 'width' et 'height' d'un élément remplacé sont à leur valeur par défaut 'auto', celles-ci adoptent les dimensions intrinsèques de l'objet qui le remplace.

On peut l'appliquer à un élément textuel et ainsi contraindre sa hauteur (ex. barre de défilement).

Les valeurs négatives ne sont pas admises.

CSS1 de base : L'agent utilisateur peut ignorer la propriété 'height' (c.-à-d., considérer sa valeur étant 'auto'), si elle est appliquée à un élément qui ne soit pas remplacé.

5.5.25 'float'

Valeur : left | right | none
Valeur initiale : none
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Pour une valeur 'none', l'élément s'affiche dans le flux normal du texte. Pour une valeur 'left' (ou 'right'), l'élément se place sur la gauche (ou droite) et le texte épouse son côté droit (ou gauche). Avec les valeurs 'left' ou 'right', l'élément acquiert un type bloc (c.-à-d. que la propriété 'display' est ignorée). Voir le chapitre 4.1.4 pour une explication complète.

IMG.icon {
  float: left;
  margin-left: 0;
}

Dans cet exemple, les éléments 'IMG' avec un attribut 'CLASS="icon"' sont positionnés au côté gauche de leur parent.

On utilise le plus souvent 'float' avec des images en ligne, mais on l'applique aussi aux éléments avec du texte.

5.5.26 'clear'

Valeur : none | left | right | both
Valeur initiale : none
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété spécifie si un élément accepte des éléments flottants contre ses bords. Plus précisément, la valeur de la propriété indique les côtés contre lesquels ceux-ci ne peuvent venir. L'élément dont la propriété 'clear' a la valeur 'left' ira se placer en-dessous de tout élément flottant qui serait à sa gauche. Avec une valeur 'none', les éléments flottants sont admis sur chacun de ses côtés. Exemple :

H1 { clear: left }

5.6 Les propriétés de classification

Ces propriétés ont plus d'intérêt pour classer des éléments en catégories que pour la spécification de paramètres visuels.

Les propriétés de liste décrivent la mise en forme des items d'une liste (les éléments avec une valeur 'list-item' pour la propriété 'display'). Ces propriétés s'appliquent à tout élément, leurs descendants en héritent mais uniquement ceux dont la propriété 'display' a pour valeur 'list-item'. En HTML, il s'agit typiquement de l'élément 'LI'.

5.6.1 'display'

Valeur : block | inline | list-item | none
Valeur initiale : block
S'applique à : tous les éléments
Héritée : non
Pourcentage : sans objet

Cette propriété spécifie si et comment un élément doit s'afficher dans le canevas (que ce soit une page, un moniteur, etc.).

Un élément dont la valeur pour 'display' est 'block' crée une nouvelle boîte. Celle-ci se positionne par rapport aux boîtes adjacentes selon le modèle de mise en forme de CSS. Les éléments' 'H1' et 'P' ont typiquement la valeur 'block'. La valeur 'list-item' confère un comportement similaire à celui de la valeur 'block', à la différence qu'une marque de liste se rajoute. En HTML, c'est la valeur typique de l'élément 'LI'.

Un élément dont la valeur pour 'display' est 'inline' crée une boîte dans le prolongement de la ligne du contenu qui précède. La boîte prend la dimension voulue pour la mise en forme de son contenu. Un contenu textuel peut s'étendre sur plusieurs lignes avec autant de boîtes de ligne. Les propriétés de marge, bordure et espacement s'appliquent aux éléments ainsi créés mais n'ont aucun effet à l'endroit des sauts de ligne.

La valeur 'none' supprime l'affichage d'un élément et de sa boîte ainsi que des éléments qu'il contient.

P { display: block }
EM { display: inline }
LI { display: list-item }
IMG { display: none }

La dernière règle supprime l'affichage des images.

La valeur initiale de 'display' est 'block', cependant l'agent utilisateur peut n'appliquer que des valeurs par défaut typiques à chacun des éléments HTML, en accord avec leur rendu suggéré dans la spécification du HTML [2].

CSS1 de base : L'agent utilisateur peut ignorer 'display' et n'utiliser que ses valeurs par défaut (cf. chapitre 7).

5.6.2 'white-space'

Valeur : normal | pre | nowrap
Valeur initiale : normal
S'applique à : éléments de type bloc tous les éléments
Héritée : oui
Pourcentage : sans objet

Cette propriété précise la façon dont sont traités les blancs dans un élément : ainsi la valeur 'normal' (les blancs fusionnent), 'pre' (qui se comporte comme l'élément 'PRE' de HTML) ou 'nowrap' (la mise à la ligne a lieu uniquement avec des éléments 'BR') :

PRE { white-space: pre }
P   { white-space: normal }

La valeur initiale de 'white-space' est 'normal', cependant l'agent utilisateur peut n'appliquer que des valeurs par défaut typiques à chacun des éléments HTML, en accord avec leur rendu suggéré dans la spécification du HTML [2].

CSS1 de base : L'agent utilisateur peut ignorer 'white-space' dans la feuille de style de l'auteur ou du lecteur et n'utiliser que des valeurs par défaut à la place (cf. chapitre 7).

5.6.3 'list-style-type'

Valeur : disc | circle | square | decimal | lower-roman | upper-roman | lower-alpha | upper-alpha | none
Valeur initiale : disc
S'applique à : ceux des éléments dont la propriété 'display' a la valeur 'list-item'
Héritée : oui
Pourcentage : sans objet

Cette propriété détermine l'apparence de la marque de liste dans le cas où la propriété 'list-style-image' a pour valeur 'none' ou quand l'image désignée par celle-ci n'est pas disponible.

OL { list-style-type: decimal }       /* 1 2 3 4 5 etc. */
OL { list-style-type: lower-alpha }   /* a b c d e etc. */
OL { list-style-type: lower-roman }   /* i ii iii iv v etc. */

5.6.4 'list-style-image'

Valeur : <url> | none
Valeur initiale : none
S'applique à : ceux des éléments dont la propriété 'display' a la valeur 'list-item'
Héritée : oui
Pourcentage : sans objet

Cette propriété désigne l'image utilisée comme marque de liste. Si l'image est disponible, elle remplace le type de marque spécifié dans 'list-type-marker'.

UL { list-style-image: url(http://png.com/ellipse.png) }

5.6.5 'list-style-position'

Valeur : inside | outside
Valeur initiale : outside
S'applique à : ceux des éléments dont la propriété 'display' a la valeur 'list-item'
Héritée : oui
Pourcentage : sans objet

La valeur de 'list-style-position' détermine la position de la marque de liste en regard de l'item en question. Voir un exemple de mise en forme au chapitre 4.1.3.

5.6.6 'list-style'

Valeur : [disc | circle | square | decimal | lower-roman | upper-roman | lower-alpha | upper-alpha | none] || [inside | outside] || [<url> | none]
Valeur initiale : non définie pour les propriétés raccourcies
S'applique à : ceux des éléments dont la propriété 'display' a la valeur 'list-item'
Héritée : oui
Pourcentage : sans objet

La propriété 'list-style' est un raccourci pour fixer et regrouper les trois propriétés 'list-style-type', 'list-style-image' et 'list-style-position' dans la feuille de style.

UL { list-style: upper-roman inside }
UL UL { list-style: circle outside }
LI.square { list-style: square }

Des résultats inattendus peuvent survenir quand on applique 'list-style' directement sur l'élément 'LI'. Ainsi :

  <STYLE TYPE="text/css">
    OL.alpha LI  { list-style: lower-alpha }
    UL LI        { list-style: disc }
  </STYLE>
  <BODY>
    <OL CLASS=alpha>
      <LI>niveau 1
      <UL>
         <LI>niveau 2
      </UL>
    </OL>
  </BODY>

La spécificité (telle que définie dans l'ordre de cascade) étant plus grande pour la première règle, celle-ci annule la deuxième règle pour tous les éléments 'LI', seule la valeur 'lower-alpha' est retenue. Il est donc recommandé de n'appliquer 'list-style' que sur les éléments de liste eux-mêmes :

OL.alpha  { list-style: lower-alpha }
UL        { list-style: disc }

Ci-dessus, les éléments 'LI' héritent des valeurs de 'list-style' des éléments 'OL' et 'UL'.

On peut combiner une valeur d'adresse URL avec chacune des autres valeurs :

UL { list-style: url(http://png.com/ellipse.png) disc }

Dans cet exemple, la valeur 'disc' est choisie si l'image n'est pas disponible.

6 Les unités

6.1 Les unités de longueur

Une valeur de longueur est formée d'un caractère optionnel ('+' ou '-', '+' par défaut) immédiatement suivi par un nombre décimal puis immédiatement encore par un identifiant d'unité (abrégé en deux lettres). L'identifiant d'unité est facultatif pour une valeur 0.

Quelques propriétés admettent des unités de longueur négatives, ce qui peut compliquer la mise en forme et qui dépend des limites propres à un agent utilisateur. Si une valeur de longueur négative n'est pas gérée, il faudrait la ramener à la plus proche valeur qui le soit.

Il y a deux genres d'unités de longueur, relatives et absolues. Les relatives se rapportent à une autre propriété de longueur. Les feuilles de styles basées sur ce genre-ci vont s'adapter plus facilement d'un média à un autre (p.ex. d'un moniteur vers une imprimante laser). Les unités de pourcentage (décrites plus bas) ainsi que les valeurs de mot-clé (ex. 'x-large') offrent les mêmes avantages.

Voici les unités relatives reconnues :

H1 { margin: 0.5em }      /* em : la taille de la police de l'élément */
H1 { margin: 1ex }        /* x-height : la hauteur de la lettre 'x' de la police de l'élément */
P  { font-size: 12px }    /* pixel : relative au canevas */

Les unités relatives 'em' et 'ex' sont relatives à la taille de la police de l'élément lui-même. La seule exception à cette règle de CSS1 est la propriété 'font-size' où les valeurs en 'em' et 'ex' sont calculées à partir de l'élément parent.

Les valeurs en pixels, telle que dans la dernière règle, sont relatives à la résolution du canevas, c.-à-d. le plus souvent celle d'un moniteur. Si la densité en pixels d'un périphérique de sortie est trop différente de celle d'un moniteur habituel, l'agent utilisateur doit adapter l'échelle des valeurs de pixel. On suggère un pixel de référence calculé ainsi : c'est l'angle visuel formé par un pixel sur un appareil de densité 90 dpi 96 dpi (ppp) situé à une longueur de bras. Ce qui donne, pour une longueur nominale de bras de 28 pouces (71 cm), un angle de 0.0227 0.0213 degrés.

L'élément enfant hérite de la valeur calculée, non de la valeur relative :

BODY {
  font-size: 12pt;
  text-indent: 3em;  /* c.-à-d. 36pt */
}
H1 { font-size: 15pt }

Dans l'exemple précédent, la valeur de 'text-indent' pour 'H1' est de 36pt et non 45pt.

Les unités de longueur absolues ne sont vraiment utiles que si on connaît les propriétés physiques du média de sortie. Voici celles qui sont reconnues :

H1 { margin: 0.5in }      /* inch (pouce) 1in = 2.54cm */
H2 { line-height: 3cm }   /* centimètre */
H3 { word-spacing: 4mm }  /* millimètre */
H4 { font-size: 12pt }    /* point 1pt = 1/72in */
H4 { font-size: 1pc }     /* pica 1pc = 12pt */

Si l'agent utilisateur ne gère pas les longueurs spécifiées, il doit essayer d'en calculer une valeur par approximation. Pour chacune des propriétés CSS1, les calculs ultérieurs ainsi que l'héritage doivent s'appuyer sur cette valeur.

6.2 Les unités de pourcentage

Une valeur en pourcentage est formée d'un caractère optionnel ('+' ou '-', '+' par défaut) immédiatement suivi par un nombre avec ou sans point décimal puis immédiatement encore par '%'.

Les valeurs de pourcentage sont toujours relatives à une autre valeur, par exemple une unité de longueur. Chacune des propriétés admettant une valeur en pourcentage définit aussi la valeur à laquelle se rapporte celui-ci. La plupart du temps, c'est la taille de la police de l'élément lui-même :

P { line-height: 120% }   /* 120% de la propriété 'font-size' de 'P' */

En CSS1 pour toutes les propriétés héritées, si leur valeur est spécifiée en pourcentage, les enfants héritent de la valeur résultante et non du pourcentage.

6.3 Les unités de couleur

Une couleur est représentée soit par un mot-clé soit par une valeur numérique de RGB.

Voici la liste suggérée des mots-clés pour les couleurs : 'aqua', 'black', 'blue', 'fuchsia', 'gray', 'green', 'lime', 'maroon', 'navy', 'olive', 'purple', 'red', 'silver', 'teal', 'white' et 'yellow'. Ils sont issus de la palette VGA de Windows, leurs valeurs RGB ne sont pas définies dans la présente spécification.

BODY {color: black; background: white }
H1 { color: maroon }
H2 { color: olive }

Le modèle de couleur RGB est utilisé pour les valeurs de couleur numériques. Ces règles produisent la même couleur :

EM { color: #f00 }              /* #rgb */
EM { color: #ff0000 }           /* #rrggbb */
EM { color: rgb(255,0,0) }      /* un entier de 0 à 255 */
EM { color: rgb(100%, 0%, 0%) } /* un pourcentage de 0.0% à 100.0% */

En notation hexadécimale, le format d'une valeur RGB se compose d'un '#' immédiatement suivi par trois ou bien six caractères hexadécimaux. La notation en trois caractères (#rgb) est convertie vers la forme en six caractères (#rrggbb) par réplication et non par l'ajout de zéros. Ainsi '#fb0' devient '#ffbb00'. Ceci assure la notation du blanc (#ffffff) en trois caractères (#fff) et en supprime la dépendance avec la profondeur de couleur de l'écran.

En notation fonctionnelle, le format d'une valeur RGB se compose de 'rgb(' suivi d'une séquence de trois valeurs numériques séparée par des virgules (soit trois entiers ayant des valeurs de 0 à 255, soit trois valeurs de pourcentage de 0 à 100%) avec un ')' final. Les blancs sont admis avant ou après les valeurs numériques.

On ramène les valeurs numériques hors-limites dans la plage autorisée. Ainsi, les trois règles suivantes sont équivalentes :

EM { color: rgb(255,0,0) }       /* entier dans la plage 0 - 255 */
EM { color: rgb(300,0,0) }       /* ramené à 255 */
EM { color: rgb(110%, 0%, 0%) }  /* ramené à 100% */

Les couleurs RGB sont spécifiées dans l'espace de couleur sRGB [9]. La conformité des agents utilisateurs dans la représentation des couleurs est variable, aussi l'utilisation de l'espace sRGB en fournit une définition objective et sans ambiguïté qui est liée à des standards internationaux [10].

Les agents utilisateurs peuvent se limiter à effectuer une correction du gamma sur les couleurs. sRGB spécifie un gamma de 2.2 pour un écran selon certaines conditions. L'agent utilisateur ajuste les couleurs spécifiées en CSS en relation avec le gamma produit "naturellement" par un dispositif d'affichage pour obtenir un gamma effectif de 2.2. L'Annexe D donne plus de détails. Noter que seules les couleurs spécifiées dans la feuille de style sont affectées, ainsi les images sont censées contenir leurs propres informations de couleur.

6.4 Les adresses URL

On identifie une adresse URL (Uniform Resource Locator) par une notation fonctionnelle :

BODY { background: url(http://www.bg.com/pinkish.gif) }

Le format d'une valeur d'adresse URL se compose de la chaîne 'url(' suivie d'un blanc optionnel puis d'un guillemet simple ('), ou double ("), optionnel aussi, vient ensuite l'adresse URL proprement dite (tel que définie dans [11]), puis à nouveau un guillemet simple, ou double, le cas échéant, un blanc optionnel et la parenthèse ')' finale. On doit apparier les marques de citation qui ne font pas partie de l'adresse URL même.

On doit masquer les parenthèses (()), les virgules (,), les blancs ( ) et les guillemets simples (') ou doubles (") contenus dans une adresse URL à l'aide du caractère oblique inverse : '\(', '\)', '\,', etc.

Une adresse URL partielle s'entend relativement à la source de la feuille de style et non au document :

BODY { background: url(yellow.png) }

7 La conformité à CSS1

Pour être déclaré conforme à la spécification CSS1, un agent utilisateur qui se sert de CSS1 pour le rendu d'un document doit :

  • charger toutes les feuilles référencées dans le document et les interpréter en accord avec cette spécification
  • classer les déclarations selon l'ordre de cascade
  • utiliser les fonctionnalités de CSS1 dans les limites imposées par le média (voir l'explication plus bas).

Un agent utilisateur qui produit des feuilles de style est conforme à la spécification CSS1 s'il :

  • produit des feuilles de style CSS1 valides

Un agent utilisateur qui utilise CSS1 pour le rendu de documents et pour la production de feuilles de style CSS1 est conforme à cette spécification s'il satisfait à ces deux conditions.

Un agent utilisateur n'est pas tenu de gérer toutes les fonctions de CSS1 mais est néanmoins considéré conforme s'il en assure les fonctions de base. Les fonctionnalités de base consistent en la totalité de la spécification CSS1 à l'exception de ce qui est explicitement exclu. Dans ce document, les passages marqués "CSS1 de base :" précisent les fonctions exclues. On les appelle aussi fonctions avancées de CSS1.

Ce chapitre ne fait que définir la conformité par rapport à CSS1. Les évolutions des feuilles de style pourront imposer la gestion d'un autre jeu de fonctions de la part des agents utilisateurs pour prétendre à une nouvelle conformité.

Quelques exemples de contraintes liées au média : des ressources limitées (polices, couleur) et une résolution réduite (ainsi les marges peuvent être imprécises). Dans ces cas, l'agent utilisateur prendra les valeurs les plus proches de celles de la feuille de style. Également, les différents paradigmes de l'interface utilisateur peuvent avoir des contraintes propres : un navigateur en Réalité Virtuelle peut redimensionner un document selon la perspective de l'utilisateur.

Les agents utilisateurs peuvent offrir des alternatives de présentation au lecteur. Par exemple, l'agent utilisateur peut fournir des options aux lecteurs handicapés visuels ou encore donner la possibilité de désactiver le clignotement.

Noter que CSS1 ne contrôle pas tous les aspects de la mise en forme. Par exemple, l'agent utilisateur est libre d'interpréter l'interlettrage.

Cette spécification recommande mais sans l'imposer qu'un agent utilisateur :

  • permette au lecteur de choisir une feuille de style personnelle
  • permette d'activer ou de désactiver les feuilles de style individuelles.

Les règles de conformité ci-dessus ne décrivent que des fonctionnalités et non l'interface utilisateur.

7.1 La compatibilité ascendante de l'interprétation

Il s'agit ici de la spécification CSS de niveau 1. Une évolution des niveaux de CSS incorporant des fonctions supplémentaires est très probable. Ce chapitre décrit ce qu'un agent utilisateur, simplement conforme à CSS1, doit faire quand celui-ci rencontrera des constructions non valides pour CSS1 dans une feuille de style.

  • une déclaration contenant une propriété inconnue est ignorée. Par exemple, pour une telle feuille de style :
      H1 { color: red; rotation: 70deg }

    l'agent utilisateur devra réagir comme si elle avait été :

    H1 { color: red; }
  • une déclaration contenant une valeur illégale ou une partie de celle-ci étant illégale est ignorée :
    IMG { float: left }       /* CSS1 */
IMG { float: left top }   /* "top" n'est pas une valeur de 'float' */
IMG { background: "red" } /* les mots-clés n'ont pas de guillemets en CSS1 */
IMG { border-width: 3 }   /* une valeur de longueur requiert une unité */

    Dans cet exemple, la première règle est interprétée en CSS1 et les autres ignorées, comme si la feuille de style avait été :

    IMG { float: left }
IMG { }
IMG { }
IMG { }

    Un agent utilisateur qui voudrait se conformer à une future spécification peut accepter une ou plusieurs des autre règles suivantes.

  • un mot-clé at (N.D.T. at-keyword) invalide est ignoré comme tout ce qui le suit jusqu'au prochain point-virgule (;) inclus ou encore la prochaine paire d'accolades ({...}), selon ce qui survient en premier. Par exemple, supposons la feuille de style suivante :
    @three-dee {
  @background-lighting {
    azimuth: 30deg;
    elevation: 190deg;
  }
  H1 { color: red }
}
H1 {color: blue}

    Pour CSS1 '@three-dee' n'est pas valide. En conséquence, la règle at (N.D.T. at-rule) en entier est ignorée (jusqu'à la troisième accolade droite incluse). L'agent utilisateur CSS1 passe sur cette instruction, ce qui réduit en fait la feuille de style à :

    H1 {color: blue}

En détail :

Quelle qu'en soit la version CSS, une feuille de style est une liste de déclarations. Celles-ci sont de deux sortes : les règles at (N.D.T. at-rule) et les ensembles de règles (N.D.T. ruleset). Il peut y avoir des blancs (espaces, caractères de tabulation ou de nouvelle ligne) autour des déclarations.

Les feuilles de style sont souvent insérées dans le document HTML. Il peut être nécessaire de les cacher aux agents utilisateurs anciens en les englobant dans des commentaires HTML. Les marques de commentaire HTML "<!--" et "-->" peuvent apparaître avant, après ou entre les déclarations. Il peut y avoir des blancs autour des commentaires.

Les règles at commencent avec un mot-clé at, un identifiant avec un '@' initial (ex. '@import', '@page'). Un identifiant est formé de lettres, chiffres, tirets et caractères masqués (voir plus bas).

Une règle at consiste en tout ce qui suit jusqu'au premier point-virgule (;) inclus ou au premier bloc (défini plus loin) qui se présente. L'interprétateur CSS1 ignore l'ensemble d'une règle at qui ne commence pas par le mot-clé at '@import' et poursuit le traitement après celle-ci. Si '@import' n'apparaît pas au début d'une feuille de style, cette règle at n'est pas interprétée, c.-à-d. si celle-ci se présente après d'autres règles (même si celles-ci sont ignorées).

Supposons un interpréteur CSS1 face à la feuille de style :

@import "subs.css";
H1 { color: blue }
@import "list.css";

Le deuxième '@import' n'est pas valide en CSS1. L'interprétation élimine celui-ci, réduisant en fait la feuille de style à :

@import "subs.css";
H1 {color: blue}

Un bloc commence par une accolade gauche ({) et se termine par une accolade correspondante droite (}). Tous caractères peuvent survenir entre celles-ci, cependant les parenthèses (()), crochets ([]) et accolades ({}) doivent toujours être appariés. On peut aussi les inclure dans une construction. De même pour les guillemets simples (') et doubles (") dont le contenu est considéré comme une chaîne (voir l'analyseur dans l'annexe B pour la définition d'une chaîne). Voici un exemple de bloc, noter que l'accolade droite entre les guillemets n'est pas appariée à l'accolade ouvrante du bloc et que le deuxième guillemet simple est masqué, il ne correspond donc pas avec le guillemet ouvrant :

{ causta: "}" + ({7} * '\'') }

Une règle se compose d'une chaîne de sélection (N.D.T. selector-string) suivie d'un bloc de déclaration. La chaîne de sélection consiste en tout ce qui précède la première accolade gauche ({), celle-ci exclue. La règle n'est pas exécutée si sa chaîne de sélection n'est pas valide pour CSS1.

Par exemple, un interpréteur CSS1 avec cette feuille de style :

H1 { color: blue }
P[align], UL { color: red; font-size: large }
P EM { font-weight: bold }

La deuxième ligne a une chaîne de sélection invalide pour CSS1. Cette instruction est sautée, réduisant la feuille de style à :

H1 { color: blue }
P EM { font-weight: bold }

Un bloc de déclaration commence par une accolade gauche ({) et finit avec l'accolade correspondante droite (}). Celui-ci contient ou non une liste de déclarations séparées par des points-virgules (;).

Une déclaration est formée d'une propriété, du caractère deux-points (:) et d'une valeur. Il peut y avoir des blancs entre chacun d'eux. Une propriété est un identifiant tel que défini plus haut. La valeur peut contenir n'importe quel caractère, cependant les parenthèses (()), crochets ([]), accolades ({}) et guillemets (' ") doivent aller de pair. Les parenthèses, crochets et accolades peuvent en faire partie. Les caractères entre guillemets sont considérés comme des chaînes.

Pour que l'ajout de futures propriétés et valeurs à celles existantes soit possible, un agent utilisateur doit ignorer une déclaration dont la propriété ou la valeur sont invalides. Les valeurs de chaque propriétés CSS1 sont soumises à des restrictions syntaxiques et sémantiques.

Pour un agent utilisateur CSS1, supposons la feuille de style :

H1 { color: red; font-style: 12pt }
P { color: blue;  font-vendor: any;  font-variant: small-caps }
EM EM { font-style: normal }

La seconde déclaration de la première règle comporte une valeur '12pt' incorrecte. La deuxième déclaration de la règle suivante indique une propriété 'font-vendor' indéfinie. L'agent utilisateur CSS1 saute ces instructions, réduisant dans les faits la feuille de style à :

H1 { color: red; }
P { color: blue;  font-variant: small-caps }
EM EM { font-style: normal }

On peut placer des commentaires (cf. chapitre 1.7) partout où les blancs sont autorisés, ils seront considérés comme des blancs. CSS1 définit ces emplacements (comme à l'intérieur des valeurs) qui concernent aussi les commentaires.

Les règles suivantes sont toujours vérifiées :

  • aucune feuille de style n'est sensible à la casse, sauf pour les parties qui ne sont pas régies par CSS, c.-à-d. pour CSS1, les noms des familles de police et les adresses URL. Cela ne s'applique pas non plus aux attributs CLASS et ID qui dépendent de HTML [2].
  • en CSS1, les sélecteurs (nom de l'élément, classes et ID) ne peuvent être formés que des caractères allant de A à Z et 0 à 9, des caractères Unicode 161 à 255, du tiret (-) ainsi que des caractères masqués et tous les caractères Unicode sous forme de code numérique (voir suivant). Ils ne peuvent pas commencer par un tiret ou un chiffre.
  • une barre oblique inverse suivie par au plus quatre hexadécimaux (0..9A..F) équivaut au caractère Unicode qui revêt ce nombre.
  • chaque caractère sauf un hexadécimal peut être masqué avec une barre oblique inverse pour annuler son sens particulier. Exemple : "\"" est une chaîne composée d'un seul guillemet double.
  • les deux articles précédents définissent le masquage par un caractère oblique inverse. Le masquage fait toujours partie d'un identifiant, sauf à l'intérieur d'une chaîne (c.-à-d., "\7B", la représentation hexadécimale du caractère ({), n'est pas une ponctuation alors que "{" l'est, tout comme "\32" est permis au début du nom d'une classe et "2" ne l'est pas).

Note : l'attribut CLASS en HTML admet plus de caractères pour le nom de la classe que pour celui des sélecteurs. En CSS1, ces caractères doivent être masqués ou prendre le modèle d'écriture Unicode : "B&W?" doit s'écrire "B\&W\?" ou "B\26W\3F" et "κουρος" ("kouros" en grec) "\3BA\3BF\3C5\3C1\3BF\3C2". Les versions ultérieures de CSS autoriseront sans doute l'introduction directe d'un plus grand nombre de caractères.

La grammaire de CSS1 se trouve à l'annexe B.

8 Références

[1] W3C resource page on web style sheets (http://www.w3.org/Style)

[2] "HTML 4.0 Specification", D. Raggett, A. Le Hors, I. Jacobs, December 1997. Available at http://www.w3.org/TR/REC-html40/.

[3] T Berners-Lee, D Connolly: "Hypertext Markup Language - 2.0", RFC1866, MIT/W3C, November 1995. The specification is also available in hypertext form (http://www.w3.org/MarkUp/html-spec/html-spec_toc.html)

[4] F Yergeau, G Nicol, G Adams, M Dürst: "Internationalization of the Hypertext Markup Language" (ftp://ds.internic.net/rfc/rfc2070.txt).

[5] ISO 8879:1986. Information Processing - Text and Office Systems - Standard Generalized Markup Language (SGML)

[6] ISO/IEC 10179:1996 Information technology -- Processing languages -- Document Style Semantics and Specification Language (DSSSL).

[7] ISO/IEC 9899:1990 Programming languages -- C.

[8] The Unicode Consortium, "The Unicode Standard -- Worldwide Character Encoding -- Version 1.0", Addison-Wesley, Volume 1, 1991, Volume 2, 1992.

[9] "A Standard Default color Space for the Internet", version 1.10, M. Stokes, M. Anderson, S. Chandrasekar, and R. Motta, 5 November 1996.

[10] CIE Publication 15.2-1986, "Colorimetry, Second Edition", ISBN 3-900-734-00-3 (http://www.hike.te.chiba-u.ac.jp/ikeda/CIE/publ/abst/15-2-86.html)

[11] T Berners-Lee, L Masinter, M McCahill: "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994

[12] "PNG (Portable Network Graphics) Specification, Version 1.0 specification" (http://www.w3.org/TR/REC-png-multi.html)

[13] Charles A. Poynton: "Gamma correction on the Macintosh Platform" (ftp://ftp.inforamp.net/pub/users/poynton/doc/Mac/Mac_gamma.pdf)

[14] International Color Consortium: "ICC Profile Format Specification, version 3.2", 1995 (ftp://sgigate.sgi.com/pub/icc/ICC32.pdf)

[15] S C Johnson: "YACC - Yet another compiler compiler", Technical Report, Murray Hill, 1975

[16] "Flex: The Lexical Scanner Generator", Version 2.3.7, ISBN 1882114213

9 Remerciements

Dans la courte existence de HTML, il y a eu plusieurs propositions de feuilles de style, la présente en est l'aboutissement. Les avis de Robert Raisch, Joe English et Pei Wei ont été déterminants.

De nombreuses personnes ont contribué au développement de CSS1. Parmi celles-ci, nous remercions particulièrement : Terry Allen, Murray Altheim, Glenn Adams, Walter Bender, Tim Berners-Lee, Yves Bertot, Scott Bigham, Steve Byrne, Robert Cailliau, James Clark, Daniel Connolly, Donna Converse, Adam Costello, Todd Fahrner, Todd Freter, Roy Fielding, Neil Galarneau, Wayne Gramlich, Phill Hallam-Baker, Philipp Hoschka, Kevin Hughes, Scott Isaacs, Tony Jebson, William Johnston, Gilles Kahn, Philippe Kaplan, Phil Karlton, Evan Kirshenbaum, Yves Lafon, Murray Maloney, Lou Montulli, Colas Nahaboo, Henrik Frystyk Nielsen, David Perrell, William Perry, Scott Preece, Paul Prescod, Liam Quin, Vincent Quint, Jenny Raggett, Thomas Reardon, Cécile Roisin, Michael Seaton, David Seibert, David Siegel, David Singer, Benjamin Sittler, Jon Smirl, Charles Peyton Taylor, Irène Vatton, Daniel Veillard, Mandira Virmani, Greg Watkins, Mike Wexler, Lydja Williams, Brian Wilson, Chris Wilson, Lauren Wood et Stephen Zilles.

Trois personnes méritent des mentions spéciales : Dave Raggett (pour ses encouragements et son travail sur HTML3), Chris Lilley (pour ses contributions incessantes, surtout dans le domaine de la couleur et des polices) et Steven Pemberton (pour ses talents d'organisateur et sa créativité).

Annexe A: Exemple de feuille de style pour HTML 2.0

(Cette annexe est informative et pas normative).

Cet exemple de feuille de style a été écrit en accord avec les principes de rendu de la spécification du HTML 2.0 [3]. Quelques styles ont été rajoutés par souci d'exhaustivité. Pour établir la feuille de style par défaut d'un agent utilisateur, il est suggéré de s'en inspirer.

BODY {
  margin: 1em;
  font-family: serif;
  line-height: 1.1;
  background: white;
  color: black;
}

H1, H2, H3, H4, H5, H6, P, UL, OL, DIR, MENU, DIV,
DT, DD, ADDRESS, BLOCKQUOTE, PRE, BR, HR, FORM, DL {
  display: block }

B, STRONG, I, EM, CITE, VAR, TT, CODE, KBD, SAMP,
IMG, SPAN { display: inline }

LI { display: list-item }

H1, H2, H3, H4 { margin-top: 1em; margin-bottom: 1em }
H5, H6 { margin-top: 1em }
H1 { text-align: center }
H1, H2, H4, H6 { font-weight: bold }
H3, H5 { font-style: italic }

H1 { font-size: xx-large }
H2 { font-size: x-large }
H3 { font-size: large }

B, STRONG { font-weight: bolder }  /* relatif au parent */
I, CITE, EM, VAR, ADDRESS, BLOCKQUOTE { font-style: italic }
PRE, TT, CODE, KBD, SAMP { font-family: monospace }

PRE { white-space: pre }

ADDRESS { margin-left: 3em }
BLOCKQUOTE { margin-left: 3em; margin-right: 3em }

UL, DIR { list-style: disc }
OL { list-style: decimal }
MENU { margin: 0 }              /* formatage serré */
LI { margin-left: 3em }

DT { margin-bottom: 0 }
DD { margin-top: 0; margin-left: 3em }

HR { border-top: solid }        /* 'border-bottom' est aussi possible */

A:link { color: blue }          /* liens non visités */
A:visited { color: red }        /* liens visités */
A:active { color: lime }        /* liens activés */

/* sélecteurs contextuels requis pour la bordure indiquant un lien autour des éléments IMG */

A:link IMG { border: 2px solid blue }
A:visited IMG { border: 2px solid red }
A:active IMG { border: 2px solid lime }

Annexe B: Grammaire de CSS1

(Cette annexe est normative).

La grammaire minimale CSS (pour toutes les versions de CSS) que doit suivre chacune des implémentations est définie au chapitre 7. La grammaire ci-dessous définit en des termes beaucoup plus réduits le langage qui décrit la syntaxe de CSS1.

C'est en quelque sorte encore un dérivé de CSS1, les contraintes de sémantique venant en plus ne sont pas exprimées dans celle-ci. Un agent utilisateur conforme doit aussi adhérer aux règles de compatibilité ascendante (chapitre 7.1), de notation des propriétés et des valeurs (chapitre 5) et de notation des unités (chapitre 6). En plus des restrictions imposées par HTML, ex. les valeurs possibles de l'attribut CLASS.

La grammaire ci-dessous est LL(1) (noter que la plupart des agents utilisateurs ne devraient pas l'utiliser directement car elle ne suit pas les conventions d'interprétation mais seulement la syntaxe CSS1). Le format des productions facilite un usage humain et quelques raccourcis de notation ne faisant pas partie de yacc [15] sont employés :

*  : 0 ou plus
+  : 1 ou plus
?  : 0 ou 1
|  : alternatives
[] : regroupement

Les productions sont :

stylesheet
 : [CDO|CDC]* [ import [CDO|CDC]* ]* [ ruleset [CDO|CDC]* ]*
 ;
import
 : IMPORT_SYM [STRING|URL] ';'		/* ex., @import url(fun.css); */
 ;
unary_operator
 : '-' | '+'
 ;
operator
 : '/' | ',' | /* vide */
 ;
property
 : IDENT
 ;
ruleset
 : selector [ ',' selector ]*
   '{' declaration [ ';' declaration ]* '}'
 ;
selector
 : simple_selector+ [ pseudo_element | solitary_pseudo_element ]?
 | solitary_pseudo_element
 ;
    /* Un "id" est un ID attaché à un type d'élément
    ** sur sa gauche comme dans : P#p007.
    ** Un "solitary_id" est un ID moins lié
    ** comme dans : #p007
    ** De même pour les classes et pseudo-classes.
    */
simple_selector
 : element_name id? class? pseudo_class?	/* ex. : H1.subject */
 | solitary_id class? pseudo_class?		/* ex. : #xyz33 */
 | solitary_class pseudo_class?			/* ex. : .author */
 | solitary_pseudo_class			/* ex. : :link */
 ;
element_name
 : IDENT
 ;
pseudo_class					/* comme dans :  A:link */
 : LINK_PSCLASS_AFTER_IDENT
 | VISITED_PSCLASS_AFTER_IDENT
 | ACTIVE_PSCLASS_AFTER_IDENT
 ;
solitary_pseudo_class				/* comme dans :  :link */
 : LINK_PSCLASS
 | VISITED_PSCLASS
 | ACTIVE_PSCLASS
 ;
class						/* comme dans :  P.note */
 : CLASS_AFTER_IDENT
 ;
solitary_class					/* comme dans :  .note */
 : CLASS
 ;
pseudo_element					/* comme dans :  P:first-line */
 : FIRST_LETTER_AFTER_IDENT
 | FIRST_LINE_AFTER_IDENT
 ;
solitary_pseudo_element				/* comme dans :  :first-line */
 : FIRST_LETTER
 | FIRST_LINE
 ;
    /* Il y a une contrainte sur id et solitary_id telle que
    ** la partie située après "#" soit une valeur ID HTML valide ;
    ** ex., "#x77" est OK, mais pas "#77".
    */
id
 : HASH_AFTER_IDENT
 ;
solitary_id
 : HASH
 ;
declaration
 : property ':' expr prio?
 | /* empty */				/* Évite les erreurs de syntaxe... */
 ;
prio
 : IMPORTANT_SYM	 		/* !important */
 ;
expr
 : term [ operator term ]*
 ;
term
 : unary_operator?
   [ NUMBER | STRING | PERCENTAGE | LENGTH | EMS | EXS
   | IDENT | hexcolor | URL | RGB ]
 ;
    /* Il y a une contrainte sur la couleur telle que celle-ci
    ** ait 3 ou 6 hexadécimaux (c.-à-d., [0-9a-fA-F])
    ** après "#"; ex., "#000" est OK, mais non "#abcd".
    */
hexcolor
 : HASH | HASH_AFTER_IDENT
 ;

Maintenant l'analyseur, écrit en notation flex [16]. Noter que cela suppose une mise en œuvre 8 bits de flex. L'analyseur est insensible à la casse (option -i en ligne de commande flex).

unicode		\\[0-9a-f]{1,4}
latin1		[¡-ÿ]
escape		{unicode}|\\[ -~¡-ÿ]
stringchar	{escape}|{latin1}|[ !#$%&(-~]
nmstrt		[a-z]|{latin1}|{escape}
nmchar		[-a-z0-9]|{latin1}|{escape}
ident		{nmstrt}{nmchar}*
name		{nmchar}+
d		[0-9]
notnm		[^-a-z0-9\\]|{latin1}
w		[ \t\n]*
num		{d}+|{d}*\.{d}+
string		\"({stringchar}|\')*\"|\'({stringchar}|\")*\'

%x COMMENT
%s AFTER_IDENT

%%
"/*"				{BEGIN(COMMENT);}
<COMMENT>"*/"			{BEGIN(0);}
<COMMENT>\n			{/* ignore */}
<COMMENT>.			{/* ignore */}
@import				{BEGIN(0); return IMPORT_SYM;}
"!"{w}important			{BEGIN(0); return IMPORTANT_SYM;}
{ident}				{BEGIN(AFTER_IDENT); return IDENT;}
{string}			{BEGIN(0); return STRING;}

{num}				{BEGIN(0); return NUMBER;}
{num}"%"			{BEGIN(0); return PERCENTAGE;}
{num}pt/{notnm}			{BEGIN(0); return LENGTH;}
{num}mm/{notnm}			{BEGIN(0); return LENGTH;}
{num}cm/{notnm}			{BEGIN(0); return LENGTH;}
{num}pc/{notnm}			{BEGIN(0); return LENGTH;}
{num}in/{notnm}			{BEGIN(0); return LENGTH;}
{num}px/{notnm}			{BEGIN(0); return LENGTH;}
{num}em/{notnm}			{BEGIN(0); return EMS;}
{num}ex/{notnm}			{BEGIN(0); return EXS;}

<AFTER_IDENT>":"link		{return LINK_PSCLASS_AFTER_IDENT;}
<AFTER_IDENT>":"visited	{return VISITED_PSCLASS_AFTER_IDENT;}
<AFTER_IDENT>":"active	{return ACTIVE_PSCLASS_AFTER_IDENT;}
<AFTER_IDENT>":"first-line	{return FIRST_LINE_AFTER_IDENT;}
<AFTER_IDENT>":"first-letter	{return FIRST_LETTER_AFTER_IDENT;}
<AFTER_IDENT>"#"{name}		{return HASH_AFTER_IDENT;}
<AFTER_IDENT>"."{name}		{return CLASS_AFTER_IDENT;}

":"link				{BEGIN(AFTER_IDENT); return LINK_PSCLASS;}
":"visited			{BEGIN(AFTER_IDENT); return VISITED_PSCLASS;}
":"active			{BEGIN(AFTER_IDENT); return ACTIVE_PSCLASS;}
":"first-line			{BEGIN(AFTER_IDENT); return FIRST_LINE;}
":"first-letter			{BEGIN(AFTER_IDENT); return FIRST_LETTER;}
"#"{name}			{BEGIN(AFTER_IDENT); return HASH;}
"."{name}			{BEGIN(AFTER_IDENT); return CLASS;}

url\({w}{string}{w}\)					|
url\({w}([^ \n\'\")]|\\\ |\\\'|\\\"|\\\))+{w}\)		{BEGIN(0); return URL;}
rgb\({w}{num}%?{w}\,{w}{num}%?{w}\,{w}{num}%?{w}\)	{BEGIN(0); return RGB;}

[-/+{};,#:]			{BEGIN(0); return *yytext;}
[ \t]+				{BEGIN(0); /* ignore les blancs */}
\n				{BEGIN(0); /* ignore les blancs */}
\<\!\-\-			{BEGIN(0); return CDO;}
\-\-\>				{BEGIN(0); return CDC;}
.				{fprintf(stderr, "%d: Illegal character (%d)\n",
                 lineno, *yytext);}

Annexe C: Codage

(Cette annexe est informative et pas normative).

Les documents HTML peuvent inclure tous les caractères Unicode parmi les quelques 30000 définis. Beaucoup de documents n'en utilisent que quelques centaines. Beaucoup de polices n'ont aussi que quelques centaines de glyphes. Cette annexe explique de pair avec le chapitre 5.2 la correspondance entre les caractères d'un document et les glyphes d'une police.

Codage des caractères

Le contenu d'un document HTML est une séquence de caractères avec un balisage. Pour la transmettre "au travers du fil", elle est encodée dans une séquence d'octets à l'aide d'un ou de plusieurs codages possibles. Le document HTML passe par une étape de décodage pour obtenir le caractère. Par exemple, en Europe occidentale, l'octet 224 est habituellement utilisé pour représenter un a-accent grave (à), mais en hébreu, cet octet représente couramment un aleph. En japonais, la signification d'un octet dépend de celui qui le précède. Dans certains codages, deux (ou plus) octets sont nécessaires pour représenter un caractère.

L'agent utilisateur s'appuie sur le paramètre de "charset" (jeu de caractères) dans l'en-tête HTTP pour décoder l'octet. "ASCII" (pour l'anglais), "ISO-8859-1" (pour l'Europe occidentale), "ISO-8859-8" (pour l'hébreu), "Shift-JIS" (pour le japonais) sont des codages (ou valeurs de charset) typiques.

HTML [2] [4] admet quelques 30000 caractères, nommément ceux définis par Unicode. Peu de documents utilisent autant de caractères différents et le choix du bon codage est généralement suffisant pour indiquer que le document ne nécessite qu'un octet par caractère. Certains caractères hors du champs de codage peuvent encore apparaître sous une forme numérique référençant le caractère : '&#928;' représentera toujours la lettre Pi majuscule, indépendamment du codage utilisé. Cela sous-entend que les agents utilisateurs doivent reconnaître chacun des caractères Unicode, même s'ils ne peuvent honorer que peu de codages.

Codage de police

Une police ne contient pas de caractères mais leurs images qu'on nomme glyphes. Sous la forme de contours ou de points, les glyphes constituent une représentation particulière du caractère. Implicitement ou explicitement, chaque police est associée à une table, la table de codage de la police, qui indique de quel caractère chaque glyphe est une représentation. Pour les polices de Type 1, on parle de la table comme du vecteur de codage.

En fait, de nombreuses polices ont plusieurs glyphes pour le même caractère. Le glyphe qui est utilisé dépend soit des règles d'usage de la langue ou soit des préférences de l'auteur.

En arabe, par exemple, chaque lettre dispose de quatre formes différentes, selon qu'elle est utilisée au début, au milieu, à la fin d'un mot ou bien isolément. Il s'agit du même caractère dans tous les cas, c'est pourquoi un seul caractère apparaît dans le document HTML, mais il semble à chaque fois différent à l'impression.

Il existe aussi des polices dont le graphiste est libre de choisir une forme entre plusieurs options possibles. Malheureusement, CSS1 ne fournit aucun moyen de les sélectionner. Seule la forme standard de ces polices est retenue pour le moment.

Jeux de polices

CSS1 autorise l'usage de jeux de polices pour obtenir l'affichage de tous les caractères dans un document ou même dans un seul élément, pour lequel parfois, une seule police ne suffit pas.

En CSS1, un jeu de police est une liste de polices, toutes de même style et taille et qui sont essayées l'une à la suite de l'autre pour y trouver un glyphe correspondant à un caractère donné. Un élément contenant du texte et des symboles mathématiques peut avoir besoin d'un jeu de deux polices, l'une avec des chiffres et des lettres, l'autre avec des symboles mathématiques. Voir au chapitre 5.2 pour une explication en détail du mécanisme de sélection des jeux de polices.

Voici un exemple de jeu de polices pour un texte censé contenir des caractères latins, japonais et des symboles mathématiques :

BODY { font-family: Baskerville, Mincho, Symbol, serif }

Les caractères latins disponibles dans la police Baskerville seront tirés de celle-ci, les japonais de Mincho et les symboles de Symbol. Tout autre caractère sera issu (heureusement) de la famille de police générique 'serif'. Cette famille de police 'serif' est utilisée si une ou plus des autres polices ne sont pas disponibles.

Annexe D: Correction du gamma

(Cette annexe est informative et pas normative).

Voir le tutoriel sur le gamma dans la spécification de PNG [12] pour ceux qui ne sont pas familiers avec ces questions.

Lors des calculs pour l'affichage sur un écran cathodique (N.D.T. CRT), l'agent utilisateur peut considérer un moniteur idéal et ignorer les effets du gamma apparent dus à la superposition du signal (N.D.T. dithering). Cela veut dire que le calcul minimum requis pour les plates-formes actuelles est :

PC avec MS-Windows
aucun
Unix avec X11
aucun
Mac avec QuickDraw
appliquer un gamma 1.39 [13] (Les applications travaillant avec ColorSync peuvent simplement passer le profil ICC sRGB [14] à celui-ci pour effectuer la correction de couleur)
SGI avec X
appliquer la valeur de gamma avec /etc/config/system.glGammaVal (la valeur par défaut étant 1.70, les applications tournant sur Irix, 6.2 ou plus, peuvent simplement passer le profil ICC sRGB au système de gestion de couleur)
NeXT avec NeXTStep
appliquer un gamma 2.22

"Appliquer le gamma" signifie la conversion de chacune des valeurs R, G et B en R'=Rgamma, G'=Ggamma, B'=Bgamma avant de les passer au système.

Cela peut être fait rapidement en construisant une table de consultation (N.D.T. lookup table) de 256 éléments au lancement du navigateur ainsi :

for i := 0 to 255 do
  raw := i / 255;
  corr := pow (raw, gamma);
  table[i] := trunc (0.5 + corr * 255.0)
end

ce qui évite des calculs astronomiques sur chaque attribut de couleur, et à plus forte raison sur chaque pixel.

Annexe E: Conditions d'application et capacité d'extension de CSS1

(Cette annexe est informative et pas normative).

Le travail effectué pour CSS1 a eu pour but la création d'un mécanisme simple de feuille de style pour les documents HTML. La spécification actuelle représente un équilibre entre la simplicité voulue pour réaliser des feuilles de style pour le Web et la pression des auteurs pour un controle visuel plus riche. CSS1 offre :

  • le remplacement du balisage visuel : les feuilles de style CSS1 remplace facilement les extensions HTML, ex. "CENTER", "FONT" et "SPACER".
  • un balisage plus élégant : au lieu d'utiliser l'élément "FONT" pour obtenir des petites capitales, une déclaration dans la feuille de style suffit. Comparons le balisage visuel :
    <H1>G<FONT SIZE=-1>ROS TITRE</FONT></H1>

    avec la feuille de style :

    H1 { font-style font-variant: small-caps }

<H1>Gros titre</H1>
  • divers niveaux d'intégration : les règles de style CSS1 peuvent provenir d'une feuille de style externe, être incluses dans l'élément 'STYLE' ou mises dans l'attribut 'STYLE'. Cette dernière option pour faciliter la transition à partir des extensions HTML vers CSS.
  • des nouveaux effets : quelques effets visuels ont été ajoutés pour la joie des utilisateurs : les pseudo-éléments typographiques et les autres valeurs de la propriété 'background' en font partie.
  • l'adaptabilité : CSS1 agit utilement sur une gamme d'appareils allant du terminal en mode texte à la station de travail en couleur haute résolution. Les auteurs peuvent écrire une feuille de style dont on peut raisonnablement penser qu'elle s'appliquera au mieux de la façon voulue.

CSS1 n'offre pas :

  • un contrôle au pixel : CSS1 favorise la simplicité sur le niveau de contrôle. Bien que l'utilisation conjointe des images de fond et des styles soit forte de possibilités, le contrôle au pixel près n'est pas possible.
  • un contrôle par l'auteur : l'auteur ne peut pas imposer l'utilisation de telle feuille de style, seulement la suggérer.
  • un langage de mise en page : CSS1 n'offre pas le multi-colonnage avec le transvasement automatique du texte, des cadres qui se superposent, etc.
  • un langage de recherche riche dans l'arborescence du document : CSS1 peut seulement remonter aux éléments parents dans l'arborescence, même si d'autres langages de feuille de style (ex. DSSSL [6]) sont dotés de capacités de recherche complètes.

CSS va s'étendre dans plusieurs directions :

  • le papier : une meilleure prise en compte de l'impression des documents HTML
  • la gestion des médias non visuels : l'ajout de nouvelles propriétés et leurs valeurs sont étudiées pour la gestion des sorties vocales et braille
  • les noms de couleur : la liste actuelle va peut être s'allonger
  • les polices : on attend des systèmes de spécification des polices plus précis pour compléter les propriétés de police existantes.
  • les valeurs et propriétés : on attend que les éditeurs proposent des améliorations au jeu des propriétés et valeurs de CSS1. La spécification peut être facilement étendue, mais l'interopérabilité entre différents agents utilisateurs est une autre histoire
  • un langage de mise en page : prise en compte de la mise en page en deux dimensions dans la tradition des applications de publication numérique.
  • d'autres DTDs : CSS1 comporte des parties spécifiquement HTML (ex. le statut particulier des attributs 'CLASS' et 'ID') qui pourraient aussi être facilement portés sur d'autres DTDs.

Ce que CSS ne risque pas de devenir :

  • un langage de programmation.

Annexe F: Changements depuis la version du 17 décembre 1996

(Cette annexe est informative et pas normative).

Ce document est une révision de la recommandation CSS1 publiée initialement le 17 décembre 1996 et la liste ci-dessous mentionne les changements apportés. En choisissant la feuille de style alterne "errata", les changements apparaissent surlignés.

Nos remerciements à Komachi Yushi, Steve Byrne, Liam Quinn, Kazuteru Okahashi, Susan Lesch et Tantek Çelik pour leur aide dans cette version révisée.

Erreurs orthographiques et typographiques

  • typo1 [section 1.1] The sentence:
    As as result, old UAs will ignore the 'STYLE' element, but its content will be treated as part of the document body, and rendered as such.

    has been changed to:

    As a result, old UAs will ignore the 'STYLE' element, but its content will be treated as part of the document body, and rendered as such.
  • typo2 [section 1.6] The sentence:
    The second selector matches matches all 'H1' elements that have an ancestor of class 'reddish'.

    has been changed to:

    The second selector matches all 'H1' elements that have an ancestor of class 'reddish'.
  • typo3 [section 2.1] The sentence:
    E.g., a style sheet can legally specify that the 'font-size' of an 'active' link should be larger that a 'visited' link, but the UA is not required to dynamically reformat the document when the reader selects the 'visited' link.

    has been changed to:

    E.g., a style sheet can legally specify that the 'font-size' of an 'active' link should be larger than a 'visited' link, but the UA is not required to dynamically reformat the document when the reader selects the 'visited' link.
  • typo4, typo5 [section 2.3-2.4] A trailing quote mark has been added to 'vertical-align'.
  • typo6 [section 4] A missing right parenthesis has been added.
  • typo7 [section 4.1] A missing comma has been added.
  • typo8 [section 4.1.2] The text:
    "If more than one of the three is 'auto', and one of them is 'width', than the others..."

    has been changed to:

    "If more than one of the three is 'auto', and one of them is 'width', then the others..."
  • typo9 [section 5.3.6] The word "Examples" has been capitalized.
  • typo10 [section 5.4.4] An entity gone astray has been corrected (from "<length&t;" to "<length>").
  • typo11 [section 5.5] The text:
    The margin properties properties set the margin of an element.

    has been changed to:

    The margin properties set the margin of an element.
  • typo12 [section 5.5.25] Superfluous quote marks have been removed.

Erreurs

  • error1 [section 2.3] A previously invalid declaration (font-style: small-caps) has been replaced by a valid one.
  • error2 [section 4] This sentence:
    CSS1 assumes a simple box-oriented formatting model where each element results in one or more rectangular boxes.

    has been replaced with:

    CSS1 assumes a simple box-oriented formatting model where each formatted element results in one or more rectangular boxes.
  • error3 [section 4.1] In this sentence:
    The top is the top of the object including any padding, border and margin; it is only defined for inline and floating elements, not for non-floating block-level elements.

    the word "object" has been replaced with "element" to use consistent terminology.

  • error4 [section 4.1.3] The alignment of the list items has been corrected.
  • error5 [section 4.1.4] There is only one P element in the example, and this sentence:
    Note that the margin of the 'P' elements enclose the floating 'IMG' element.

    has therefore been corrected to:

    Note that the margin of the 'P' element enclose the floating 'IMG' element.
  • error6, error7 [section 4.5] The window size can only influence one axis of the canvas, either the width or the height.
  • error8 [section 5.4.1] The text inside the parenthesis now refers to a CSS1 property.
  • error9 [section 5.4.1] To correspond with the following paragraph, the example has been corrected.
  • error10 [section 5.4.8] The section "The height of lines" is now correctly identified as section 4.4, not 4.7.
  • error11 [section 5.5] This sentence:
    The 'margin' property sets the border for all four sides while the other margin properties only set their respective side.

    has been corrected to:

    The 'margin' property sets the margin for all four sides while the other margin properties only set their respective side.
  • error12, error13, error14, error15, error16, error17, error18, error19, error20, error22 [section 5.5.1-5.5.10] Percentage values refer to width of the closest block-level ancestor, not the parent element (which can be inline) as previously stated.
  • error21 [section 5.5.10] Shorthand properties don't have initial values, and the previously specified '0' has therefore been corrected.
  • error23 [section 5.5.15] The last rule in the example previously contained an illegal value ('none').
  • error24 [section 5.6.6] The value specification on the 'list-style' property had been corrected, but there are no syntactic or semantic changes.
  • error25 [section 7.1] The numeric character references used to encode the Greek word "kouros" have been corrected.
  • error26 [Appendix A] These element types have been added to the list of selectors attached to the 'display: block' declaration: FORM DL.
  • error27 [Appendix B] A dead link to section 7 has been fixed.
  • error28 [Appendix D] This text:
    "Applying gamma" means that each of the three R, G and B must be converted to R'=Rgamma, G'=Ggamma, G'=Bgamma, before handing to the OS.

    has been changed to:

    "Applying gamma" means that each of the three R, G and B must be converted to R'=Rgamma, G'=Ggamma, B'=Bgamma, before handing to the OS.

Structure et Organisation

  • Appendix F, which lists all changes since the 17 December 1996 version has been added.
  • A paragraph in the status section has been added to inform readers that this is a revised version.
  • The style sheet has changed.
  • The reference to a future HTML specification with support for style sheets has been updated to reference HTML 4.0.
  • Les adresses URL in the References have been updated, and dead links have been removed.
  • The underlying HTML markup has been revised.


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro !

Par Joe Gillespie

Cet article est le premier d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Introduction

Si l'idée d'utiliser des Feuilles de Styles en Cascade vous effraie, tranquillisez-vous. Le fait d'utiliser un ordinateur peut être terrifiant pour quelqu'un qui le découvre pour la première fois, mais après un certain temps, on n'y pense plus. Le tout, c'est d'y aller par petites étapes au départ, et c'est ce que je compte faire dans cette série de tutoriels. Une étape à la fois !

Que vous utilisiez un éditeur WYSIWYG sans jamais vous occuper du code source qu'il y a derrière, ou même si vous n'avez jamais créé la moindre page Web, ce tutoriel va vous mettre dans la bonne direction.
Je pars du principe que vous ne savez rien, ou pas grand-chose, de la façon dont on monte une page Web. Il s'agit vraiment de « tout reprendre à zéro ! »

De quoi aurez-vous besoin?

De rien de particulier. Si vous avez un éditeur de page web, très bien. Sinon, vous pouvez utiliser n'importe quel éditeur de texte : Bloc-Notes sur un PC, ou alors SimpleText ou TextEdit sur un Mac. Si vous utilisez déjà DreamWeaver ou GoLive, sachez que nous allons utiliser le mode « source. »

Pas de panique ! Un éditeur graphique n'est pas essentiel, parce que je ne vais pas trop m'occuper de graphiques pour commencer.

Ah, vous aurez besoin d'un navigateur, ça va sans dire. En fait, je recommanderais de prendre plusieurs navigateurs différents. Si vous ne disposez que d'Explorer, vous devriez également prendre Mozilla ou d'autres dans cette liste des Nouveaux Navigateurs ( établie en février 2004 et non remise à jour, NdT ).

Si vous voulez télécharger vos pages vers un serveur Web, vous aurez besoin d'un programme FTP standard, mais ne vous en inquiétez pas pour l'instant, tout va être fait sur votre ordinateur.

Première étape : une page de base

Avant toute chose, il nous faut une page Web de base. Voici la page Web la plus simple possible.

<html>
 <head>
 </head>
 <body>
Voici ma page Web
 </body>
</html>

Nous avons ici trois ensembles de « balises »; les balises vont généralement par paires, mais pas toujours. Celle qui englobe toute la page est la paire de balises <html>...</html>. La première <html> est la « balise ouvrante », et la « balise fermante » est identique sauf qu'elle a un caractère de barre oblique entre le < et le html>.

À l'intérieur de la balise html se trouvent deux autres paires de balises.

La partie <head>...</head> contient des informations qui ne vont pas se voir sur votre page Web, la plus importante étant le titre qui apparaît dans la barre de titre de votre navigateur. Il faut insérer le titre de votre page entre une paire de balises de titre comme ceci...

<html>
<head>
<title>Ma page</title>
</head>
<body>
Voici le contenu de ma page Web !
</body>
</html>

La paire de balises <body>...</body> contient l'intégralité de votre page Web, le texte, les images, les animations Flash, tout ce que vous voulez. Vous pouvez soit taper le code dans votre éditeur de texte ou dans la fenêtre « source » d'un éditeur WYSIWYG, soit le copier-coller à partir d'ici.

Mon HTMLéphant, moyen mnémotechnique visuel pour l'ordre des balises
Voici mon HTMLéphant. Bon d'accord, ce n'est pas très original, mais au moins vous vous en souviendrez !

Donc, vous voilà avec une page Web qui fonctionnera dans n'importe quel navigateur (une fois que vous l'aurez enregistrée). Appelez-la « index.html », parce que c'est le nom de la première page sur tous les sites Web. Vous pouvez enregistrer le fichier n'importe où sur le disque dur de votre ordinateur, mais pour que les choses restent bien en ordre, créez un nouveau dossier pour y ranger vos pages Web.

La façon normale d'ouvrir votre page dans le navigateur est d'utiliser la commande « Ouvrir » dans le menu « Fichier » du navigateur, mais il y a un moyen plus rapide. Créez un raccourci pour votre fichier ou copiez-le, et placez-le sur le bureau. À partir de là, vous n'aurez qu'à faire glisser à la souris l'icône de votre fichier vers la fenêtre du navigateur, et votre page apparaîtra dans toute sa splendeur ! Elle devrait ressembler à ceci.

Bien qu'elle soit merveilleuse, il manque à votre page web un ingrédient essentiel : du contenu. Ça ne rime pas à grand-chose d'avoir une page Web si elle ne dit rien d'intéressant (en-dehors de « Voici le contenu de ma page Web ! »), mais c'est votre affaire.

Quel que soit le contenu, il devra être inclus entre la paire de balises <body>...</body> pour que le navigateur l'affiche.

Tant qu'on se contente de placer un texte dans une page Web nue comme ici, il n'a ni structure, ni style. Quand je parle de structure, je veux dire que les mots vont de gauche à droite et de haut en bas sans autre mise en valeur que l'ordre dans lequel ils apparaissent. Il est plus logique de regrouper ces mots et ces phrases en paragraphes, titres, sous-titres : bref, vous voyez, les trucs de base qu'on vous a appris à l'école.

Les navigateurs ignorent les retours à la ligne ou les paragraphes que vous avez dans votre texte brut. Ils ignorent aussi les tabulations, et si vous avez placé plus d'un espace entre deux mots, ils ignoreront également les espaces supplémentaires.

Il est utile, dans presque tous les textes, d'avoir un titre, un sous-titre, quelques paragraphes distincts et peut-être une signature à la fin.

Dans le HTML, le mécanisme permettant de faire ceci est fourni par encore d'autre balises de mise en forme.

On crée un paragraphe en incluant du texte au sein d'une paire de balises <p>...</p>. Un paragraphe en HTML, c'est tout simplement un bloc de texte d'une ou plusieurs phrases avec un petit bout d'espace pour le séparer du suivant : exactement comme ici.

Pour les titres, il y a six différents degrés de mise en valeur, qui vont du plus élevé <h1>...</h1> jusqu'au plus bas <h6>...</h6>. Ils ressemblent à ceci...

Voici un titre h1

Voici un titre h2

Voici un titre h3

Voici un titre h4

Voici un titre h5
Voici un titre h6

Comme vous le voyez, leur taille diminue quand la valeur de leur chiffre augmente, le <h4> faisant à peu près la même taille que la « petite » police du texte que vous lisez ici. <h5> et <h6> sont plus petits, mais en caractères gras.

Il existe une poignée d'autres petites astuces qui permettent de jouer avec le texte pour mettre en valeurs certains mots ou expressions. Plutôt que de penser à leur aspect, réfléchissez à leur fonction réelle.

Le caractère gras est une version plus lourde de la police de texte, et se marque par <b>...</b>. Toutefois, le mot « gras » est un terme de style pour l'impression, et sur le Web il est préférable d'utiliser <strong>...</strong>. Même si cela revient au même sur votre écran, le HTML doit aussi fonctionner sur d'autres supports. Les logiciels qui lisent les pages Web aux personnes malvoyantes comprendront ce strong et le prononceront avec la force nécessaire.

L'italique s'applique, vous l'aurez deviné, grâce à <i>...</i>. Là aussi, avec HTML, mieux vaut ne pas utiliser ce style visuel mais plutôt <em>...</em>. On obtient ainsi un effet d'italique quel que soit l'outil qui reproduit le texte.

Le soulignement peut s'effectuer avec la paire de balises <u>...</u> mais un soulignement dans une page Web a un sens particulier. Il sert généralement à indiquer un lien. Mieux vaut ne pas utiliser le soulignement comme mode de mise en valeur, cela peut créer une confusion pour les lecteurs.

L'autre balise importante est le retour à la ligne <br>. Contrairement aux autres balises, celle-ci ne requiert pas de balise fermante, qui n'aurait pas beaucoup de sens d'ailleurs : où la mettrait-on ?

En utilisant ces balises de mise en forme de base, le texte commence à prendre forme. Il devient plus proche de ce que vous pourriez produire avec un traitement de texte.

Cette page de base aura sans doute un aspect différent dans d'autres navigateurs et sur d'autres ordinateurs. Chaque navigateur a un ensemble de styles par défaut, et sauf instruction contraire de votre part, il utilisera ces données par défaut. Pour ignorer ces styles par défaut, nous allons tout simplement produire nos propres styles qui seront regroupés dans une « feuille de styles » collective.

Épisode 2 »

Fiche technique

  • Article original : CSS from the Ground Up
  • Auteur : Joe Gillespie
  • Date de parution : 1 janvier 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : mars 2005
  • Thème : CSS
  • Niveau : Débutant

À propos de l'auteur

Joe Gillespie est un web designer qui partage ses passions pour le design, les CSS et la typographie depuis 8 ans sur son site Web Page Design for Designers. Il a pris sa retraite du Web cette année, au terme de 80 publications mensuelles. Dommage pour nous !


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (épisode 2)

Par Joe Gillespie

Cet article est le deuxième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Deuxième étape : Une Feuille de Style.

Une feuille de style est un concept assez simple, c'est une page de définitions ou de caractéristiques concernant le style qui indiquent au navigateur comment afficher les divers éléments d'une page. Si vous vous demandez où le terme de « cascade » va arriver, ne vous inquiétez pas encore à son sujet. J'y reviendrai plus tard quand nous commencerons à appliquer les styles à notre HTML.

Pour faire simple, nous allons écrire notre feuille de style dans la page Web. Plus tard, vous constaterez que vous pouvez avoir une « feuille de style externe » dans un fichier séparé, qui peut être appelé par plusieurs pages. Le grand avantage, c'est qu'une seule modification dans cette feuille de style principale affectera toutes les pages qui lui sont liées.

Les styles que nous allons employer sont définis dans la partie <head>…</head> de notre page comme ceci :

<style type="text/css" title="mes_styles" media="all">
<!--

-->
</style>

Ici, vous voyez une paire de balises <style>…</style> mais il y a en plus quelques attributs qui ont besoin d'être expliqués.

type="text/css" indique au navigateur que nous utilisons juste du texte pour décrire les styles, aucune fantaisie ici.

title="mes_styles" identifie simplement le style pour votre propre information.

media="all" C'est là où ça commence à devenir intéressant. Vous pouvez avoir une feuille de style pour décrire à quoi ressemble votre page sur un écran d'ordinateur (media="screen") et une autre complètement différente pour définir l'impression (media="print"). Il y existe d'autres médias comme « projection », « tv », « braille » et « aural ». Maintenant vous pouvez comprendre la logique de ne pas employer « bold » et « italic ». Pour l'instant, nous emploierons seulement « all », qui est pour tous les usages.

Les caractères <!-- et --> sont une manière de cacher le texte sur une page Web, on peut seulement le voir dans le code. Ceci s'appelle « commenter » mais comme les styles sont définis dans la section <head>…</head> de la page, ils ne devraient pas apparaître de toute façon.

La première chose que nous allons faire est de définir le style du corps de la page. Tout ce qui est contenu entre les balises <body>…</body> se verra appliquer ce ou ces styles.

La définition de base de la partie « body » ressemble à ceci : le mot body suivi d'une paire d'accolades.

body {}

Nous allons donner à la page une couleur de fond …

Le style par défaut des navigateurs donne habituellement du texte noir sur une page blanche, mais nous allons changer cela en un gris pâle plus chaud. Voici comment nous définissons une valeur pour la couleur de fond du corps de la page. Notez que nous n'employons pas un signe égale « = » mais deux points « : ».

body { background-color: #e8eae8 }

Qu'est-ce que c'est, #e8eae8 ?

Les couleurs sur les pages Web sont définies en mélangeant 256 nuances de rouge, de vert et de bleu dans diverses proportions. Les humains ont 10 doigts sur leurs mains, donc ils comptent par dix. Les ordinateurs préfèrent compter par seize, bien qu'ils n'aient pas de doigts, mais une fois que vous allez au-dessus de neuf, il n'y a aucun numéro pour représenter 10, 11, 12, 13, 14, et 15. Aussi nous leurs substituons les lettres a, b, c, d, e, f. Ainsi, quand on compte en « hexadécimal », 10 est représenté par « a » et 15 par « f ». Quand vous allez au-dessus de 15, vous ajoutez un deuxième chiffre et « 10 » représente 16. En utilisant cette méthode, tous les nombres de 0 à 255 peuvent être représentés par deux nombres ou lettres. 255 équivaut ainsi à FF, #ffffff sera du blanc et #000000 du noir.

Notre couleur de fond est donc rouge e8 (232), vert ea (234), bleu e8 (232). Le signe dièse devant précise qu'il s'agit de nombres hexadécimaux et non de décimaux ordinaires.

Parfois vous verrez seulement trois caractères, par exemple, #2a0. C'est une notation courte pour 22aa00. Quand il y a les deux mêmes caractères dans chacune des trois valeurs de couleur, vous pouvez vous passer du second caractère et votre navigateur comprendra ce que cela signifie.

En utilisant seulement trois chiffres, vous pouvez avoir 4096 couleurs différentes. Avec six chiffres, les possibilités sont de seize millions.

rouge, vert et bleu

Avec des couleurs à un seul chiffre, le rouge, le vert et le bleu ont chacun 16 étapes de luminosité, qui peuvent être combinées de nombreuses façons afin de produire toutes les autres.

Combinaison de couleurs

Si vous codez à la main, employer des valeurs de couleur à trois chiffres est plus simple et probablement suffisant.

Quoi qu'il en soit, ajoutons maintenant une couleur pour la police afin de remplacer le noir. Elle a été choisie avec l'outil « pipette » dans Photoshop, c'est ainsi un nombre hexadécimal de 6 chiffres …

body { background-color: #e8eae8; color: #5d665b }

Notez comment la couleur de fond et la couleur de premier plan (pour le texte) sont séparées par un point-virgule. Faites attention à ne pas mélanger les deux points et les points-virgules ou les choses tourneront vraiment mal.

Et maintenant, de façon à ce que le texte ne s'étende pas jusqu'aux bords de notre page, nous pouvons entourer la page d'une marge. « margin : 50px » est ajouté à notre définition de style pour la partie « body », de nouveau séparée de la précédente par un point-virgule.

body {
 background-color: #e8eae8;
 color: #5d665b;
 margin: 50px
}

N'importe quel texte que nous ajouterons maintenant à la page sera par défaut d'un gris-vert foncé sur un fond gris pâle. Nous verrons plus tard comment ceci peut être redéfini pour des cas spéciaux.

Fiche technique

  • Article original : CSS from the Ground Up -2
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Valentin
  • Date de traduction : avril 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (épisode 3)

Par Joe Gillespie

Cet article est le troisième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Troisième étape : appliquer du style au texte

Nous nous sommes déjà débarrassés du côté brut du noir et blanc pour le remplacer par quelque chose de plus doux, mais on peut faire beaucoup plus. On peut changer la police d'écriture, la taille des caractères, la quantité d'espace entre les lignes et ajouter des détails de mise en valeur comme des retraits de paragraphes.

La police d'écriture

Nous allons commencer par le style de police, dans la mesure où c'est ce qui va apporter le plus grand changement. À la différence du papier, les pages Web ne peuvent utiliser que les polices qui sont installées sur l'ordinateur de l'utilisateur : on ne peut donc pas se contenter d'indiquer la police qui nous plaît le plus, il faut utiliser celles qui sont communes à tous les ordinateurs (celles qui sont préinstallées avec le système). Cela réduit considérablement le choix. Vous allez vous apercevoir que vous êtes limités à deux ou trois polices serif, à autant de sans-serif et à un style de type machine à écrire, à espacement constant : monospace. Au lieu de ne choisir qu'un seul style de police, on indique une famille, dans l'espoir qu'une d'entre elles sera installée sur l'ordinateur du visiteur.

Exemples de polices pour le Web

Ci-dessus : quelques polices courantes sur les ordinateurs Windows et Mac. Vous ne pouvez jamais être certain que telle ou telle police est présente, il faut donc fournir des alternatives.

Voici une indication courante de famille de polices sans-serif :

font-family: Verdana, Geneva, Arial, sans-serif;

Voici une famille de polices serif :

font-family: Georgia, "Times New Roman", Times, serif;

Remarquez que lorsque le nom d'une police contient plus d'un mot, l'ensemble doit être placé entre guillemets à l'anglaise : "Times New Roman".

Ajoutons les polices sans-serif à nos styles et voyons ce que ça donne.

Notre page en police sans-serif >>

La taille des caractères

La question de la taille qu'on assigne aux caractères est très délicate. Pour l'impression, on peut fixer une taille de police en points, et le caractère aura toujours cette même taille. Il occupera toujours le même espace sur la page, et les retours à la ligne seront toujours à l'endroit que vous aurez choisi.

Sur le Web, les tailles de caractères ne sont pas gravées dans le marbre, et elles peuvent changer d'un ordinateur à l'autre, parfois du tout au tout. En fonction de la taille de l'écran de l'internaute, de son système d'exploitation et de son navigateur, les caractères peuvent devenir tellement petits qu'ils en sont illisibles, ou aussi grands que dans des méthodes de lecture pour enfants. Les internautes ont heureusement la possibilité de choisir une taille « confortable » dans les préférences de leur navigateurs, et donc de réduire un peu ces variations de taille, mais le résultat peut rester très différent de ce que vous attendiez.

Vue la popularité grandissante du Wi-Fi et des systèmes de poche, les modes de navigation sur vos pages vont changer radicalement dans les prochaines années. Pour que vos pages restent lisibles à long terme, vous devez raisonner en termes de maquettes liquides qui s'adaptent à la taille de l'écran.

Répétez après moi : « Le Web, ce n'est pas la même chose que le papier ! »

Tailles de caractères relatives

Si vous voulez que vos pages touchent le plus large public, mieux vaut assigner une taille de caractères relative à la taille que le visiteur aura choisie par défaut. Il y a plusieurs façons d'assigner des tailles de caractères relatives. Vous pouvez utiliser des pourcentages de la valeur par défaut (%), ou bien une unité nommée « em », qui correspond à 100%. 1.2em revient à 120%. La meilleure méthode est d'utiliser un ensemble de descriptions pré-définies qui font penser à des tailles de tee-shirts. « Medium » revient à 100%, ou 1em. « Smaller » est une taille en-dessous, et « Larger » une taille au dessus. Il y a aussi x-small, xx-small, x-large et xx-large. L'intérêt d'utiliser ce système par rapport aux pourcentages ou aux ems, c'est que les navigateurs ne laisseront pas la police d'écriture devenir si petite qu'on ne puisse plus la lire. Imaginez, par exemple, que vous indiquiez une taille de caractères de 0.7em ou de 70% qui rendrait très bien sur votre PC. Pour quelqu'un équipé d'un Mac avec une taille de caractères par défaut plus petite, ce 70% pourrait faire passer vos caractères sous le seuil de la lisibilité. xx-small est une bonne solution pour déterminer quelle est la taille de caractères minimum que l'ordinateur peut afficher.

xx-large x-large large medium small x-small xx-small

Caractères xx-small : C'est petit mais le texte reste lisible
Avec une taille fixe trop petite : C'est beaucoup trop petit

Tailles de caractères absolues

Si votre site ne concerne qu'un nombre limité de visiteurs qui utilisent à peu près le même type d'ordinateur que vous, vous pouvez également indiquer des tailles de caractères en pixels. Les pixels ne varient pas tellement d'un ordinateur de bureau à l'autre, et la taille des caractères sera similaire, sinon identique. Dès que l'on passe à des ordinateurs portables ou bien de poche, ou encore à des moniteurs très grands et à haute résolution, les tailles de pixels s'éloignent de la norme, et la taille des caractères sera modifiée d'autant.

Pour que vous puissiez percevoir les différences, j'ai placé ci-dessous trois paragraphes de texte en utilisant trois méthodes : les pourcentages, les tailles de tee-shirts et les pixels. Sur mon écran sous Mozilla, leurs tailles sont quasi-identiques, mais ce n'est peut-être pas le cas sur le vôtre.

Cette ligne est définie à 85% de la taille du texte qui l'entoure.
Cette ligne est définie en x-small.
Cette ligne est définie à 11px absolument.

Notez qu'il ne faut jamais utiliser les « points » pour indiquer des tailles de caractères, c'est une unité d'impression.

L'interlignage

La quantité d'espace entre les lignes est d'environ 120% de la taille de caractères par défaut. On peut en ajouter un peu plus, ce qui améliore généralement la lisibilité, surtout si les lignes sont longues. J'évoquerai la longueur des lignes plus tard. Dans notre page d'exemple actuelle, la longueur des lignes est déterminée par la largeur de la fenêtre du navigateur, donc elle est peut-être plus grande qu'il ne faudrait.

Pour changer l'interlignage, nous avons à nouveau l'option relative (en % ou en ems) ou absolue (en px). Dans notre exemple, j'ai indiqué une hauteur de ligne (line-height), c'est-à-dire la hauteur du caractère et de l'espace supplémentaire au dessus, à 180% de la taille de caractères (small) pour toute la page. Comme la définition du style de la partie « body » commence à être un peu longue, je l'ai séparée en plusieurs lignes. Le navigateur s'en moque, mais c'est plus facile à lire par des humains. Tant que les accolades sont présentes et que chaque définition de style est séparée des autres par un point-virgule, tout va bien.

body {
background-color: #e8eae8;
color: #5d665b;
margin: 50px;
font-family: Verdana, Geneva, Arial, sans-serif;
font-size: small;
line-height: 180%
}

Nous avons maintenant une page plus « aérée » >>

Les paragraphes

Tout ce que nous avons réalisé jusqu'à présent concernait l'ensemble de la page. Maintenant nous allons voir comment appliquer notre style à des zones plus précises.

Comme je l'ai évoqué précédemment, de gros morceaux de texte peuvent être découpés en paragraphes pour les rendre plus faciles à lire. Il existe plusieurs façons de séparer visuellement les paragraphes. On peut ajouter de l'espace supplémentaire, ou pourquoi pas faire un retrait de première ligne.

En typographie créative, les designers souhaitent parfois utiliser d'autres techniques moins courantes, comme un retrait d'à peu près la moitié de la largeur de la colonne, ou un retrait négatif. Les CSS sont capables de gérer tout cela, mais le séparateur de paragraphes par défaut est un « espacement de paragraphe » qui fait à peu près la moitié de la hauteur de ligne (line-height).

Pour qu'un bloc de texte devienne un paragraphe, contentez-vous de l'encadrer par une paire de balises <p>...</p>. Pour pouvoir manipuler le style des paragraphes avec CSS, on ajoute p { } aux définitions de style dans la partie « head » de la page, à la suite des styles pour « body ». Entre les accolades, ajoutez text-indent: 3em; (indent est le mot anglais pour « retrait », NdT)

 <style type="text/css" title="mes_styles" media="all">
<!--
body { background-color: #e8eae8;
color: #5d665b;
margin: 50px;
font-family: Verdana, Geneva,
Arial, sans-serif;
font-size: small;
line-height: 180%
}

p { text-indent: 3em
} -->
</style>

Cette page est divisée en paragraphes >>

Remarquez que le premier paragraphe ne présente pas de retrait : il n'est pas encadré par <p>...</p>, donc ce n'est pas officiellement un paragraphe (en termes de HTML).

Les titres

J'ai déjà expliqué les six niveaux de titre que le HTML propose par défaut. Rien ne nous oblige à les conserver tels quels, nous pouvons les redéfinir selon nos besoins. Là encore, il ne s'agit que d'ajouter d'autres définitions aux styles.

Par défaut, les titres sont en grands caractères gras, et dotés d'espacements supplémentaires au-dessus et en-dessous. Souvenez-vous que les titres h1, h2 et h3 sont plus gros que le texte normal, tandis que h5 et h6 sont plus petits. Amusons-nous avec un titre h3 pour changer sa couleur et sa police de caractères.

h3 {color: #966b72; font-family: Georgia, "Times New Roman", Times, serif }

Nous avons maintenant des titres >>

Vous remarquez peut-être que j'ai ajouté une ligne vide sous le deuxième titre. Si vous vous contentez de mettre un paragraphe vide (<p></p>) cela ne marchera pas, il doit y avoir quelque chose entre les balises. Un espace ne fonctionnera pas non plus (<p> </p>) parce que HTML ignore les espaces s'ils ne sont pas entre deux caractères. Ce dont nous avons besoin, c'est d'un caractère invisible que nous fournit HTML sous le nom d'espace insécable que l'on peut taper &nbsp; comme ici :

 <p>&nbsp;</p>

L'espace insécable est également très utile placé entre deux mots que vous ne souhaitez pas voir séparés lorsque la ligne se termine : des noms de personnes ou d'entreprises par exemple.

D'autres petites manips

Avant d'aborder la partie suivante, essayons de modifier quelques petites choses dans notre page de texte.

Dans la définition de la partie « body », j'ai mis une marge de 50 pixels pour tous les côtés. Il est possible d'avoir différentes marges pour la gauche, la droite, le haut et le bas. Il n'y a qu'à les séparer comme ceci (respectivement marge du haut, de gauche, de droite et du bas, NdT) :

margin-top: 70px;
margin-left: 120px;
margin-right: 50px;
margin-bottom: 70px;

Cela va donner quelque chose plus proche d'une page imprimée, avec une marge de gauche plus importante. J'ai aussi appliqué à deux ou trois mots du gras (strong) et des italiques (em). Attention, les italiques rendent mal sur certains ordinateurs, et deviennent particulièrement difficiles à lire quand la taille est réduite.

Voyez notre page quand le texte a reçu ses styles >>

Désormais, vous disposez d'une page qui commence à avoir du style, et sans avoir fourni trop d'efforts. Toutefois, elle ressemble encore à un document tapé à la machine ou à l'aide d'un traitement de texte. Dans le prochain article, nous verrons d'autres possibilités de mise en page plus intéressantes.

En attendant, vous pouvez vous amuser avec les valeurs des styles de la page que vous venez de créer. Essayez différentes polices et tailles de caractères, différents interlignages. Mais surtout, visionnez votre page avec autant de navigateurs différents que possible, pour observer toutes les différences de rendu.

Épisode 4 »

Fiche technique

  • Article original : CSS from the Ground Up -3
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : avril 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (épisode 4)

Par Joe Gillespie

Cet article est le quatrième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Quatrième étape : plus de mise en forme pour le texte

Avant d'aller plus loin dans la mise en forme du texte, c'est une bonne idée de vous familiariser avec quelques termes basiques de typographie.

Quand nous parlons de la taille de la police, ou font-size en CSS, cela fait référence à la distance entre le sommet d'une lettre majuscule comme « A » jusqu'au bas d'une lettre à jambage comme « p » ou « y ». Il peut aussi y avoir un léger espace supplémentaire appelé « interlignage ». Ce mot vient du fait que les imprimeurs utilisaient des petites lattes de plomb entre les lignes pour leur donner plus d'espace. ( NdT : En anglais, « interlignage » se dit « leading » et le plomb se traduit « lead ».)

anatomie d'une lettre

Aujourd'hui, on n'utilise plus de plomb. On dit juste qu'il y a un certain espace entre la base d'une ligne de caractères et la suivante. L'interlignage est donc la hauteur du caractère plus cet espace supplémentaire. Dans une définition CSS, nous pourrions dire line-height: 180%; avec la valeur spécifiée en pourcentage, em ou pixels (px). On reviendra sur l'interlignage un peu plus loin.

Vertical-align vous permet d'ajuster la ligne de base pour des lettres individuellement par rapport au reste du texte mais relève plutôt pour un usage spécialisé (comme les formules mathématiques), et on ne va pas s'étendre sur son cas ici. Dans l'exemple basique ci-dessous, j'aurais pu utiliser la balise <sup>2</sup> mais le recours à CSS permet plus de contrôle.

P=RI2

<span class="red" style="font-size: xx-large;"> &nbsp;&nbsp;&nbsp;&nbsp;P=RI<span style="font-size: medium; vertical-align: 80%;">2</span> </span>

Les CSS nous donnent également le contrôle sur l'interlettrage (ou crénage), c'est-à-dire l'espace entre chaque caractère ou mot.

C'est très pratique pour ajouter un style visuel à un gros titre.

UN TITRE ESPACÉ.

letter-spacing: 0.5em; word-spacing: 0.5em

Penser à la lisibilité

Avant que les navigateurs ne supportent aussi bien les CSS qu'à l'heure actuelle, il y avait une caractéristique essentielle qui manquait au formatage du texte en HTML, et que maîtrisait même la plus modeste des machines à écrire , l'interlignage. Quand il y a trop peu ou pas du tout d'espace entre les lignes, elles deviennent déprimantes et difficiles à lire. Et plus les lignes s'allongent, plus le problème s'accentue.

Des lignes trop courtes
interrompent trop
le schéma de lecture
de l'œil de la gauche
vers la droite.

Des lignes plus longues que la normale sont aussi fatigantes et le début de la ligne suivante devient difficile à localiser.

Pour une lecture confortable, une ligne de texte devrait être de la même longueur que une fois et demie à deux fois la longueur d'un alphabet en minuscules. Ce qui signifie entre quarante et soixante caractères ou huit à dix mots.

Si les lignes sont plus longues, un interlettrage plus grand aide à la lisibilité. Au début, beaucoup de pages web avaient leurs textes qui s'étendaient d'un bord à l'autre de la fenêtre, sans se soucier de la taille d'écran. Les écrans sont devenus plus larges, mais la pratique continue chez certains.

Par défaut, il y a un petit interlettrage dans les paramètres de texte des navigateurs. C'est approximativement 20 % de la taille de la police (hauteur d'une majuscule plus le jambage inférieur). Avec CSS vous pouvez avoir autant d'interlignage que vous le souhaitez. Si vous utilisez des tailles de polices relatives, vous pouvez le spécifier comme un pourcentage de la taille de la police. Exemple : font-size: 1em; line-height: 1.5em (ce qui équivaut à 150%). Si vous utilisez des tailles de polices fixes, vous pouvez indiquer quelque chose comme : font-size: 11px; line-height: 16px .

La définition pour cette page (NdT: la page originale de l'auteur) est font-size: small; line-height: 180% ce qui correspond à peu près à une fois et demie l'interlignage dans un traitement de texte ou une ancienne machine à écrire. Ainsi, dans cet exemple le haut de la page n'a pas de marges et le texte n'a pas de paramètres d'interlignage. Les spécifications générales pour l'élément body de la page fournissent la famille de police, la taille de la police et les couleurs pour les caractères et le fond de la page.

body {
color: #5d665b;
font-size: small;
font-family: Verdana, Geneva, Arial, sans-serif;
background-color: #e8eae8
}

Le bloc de texte en bas de l'exemple est encapsulé dans une division de la page <div>...</div> . C'est comme une page dans une page. Elle possède une marge gauche de 250px, une marge droite de 200px, et l'interlignage est défini à 180%. Ces styles sont ajoutés aux spécifications générales de l'élément body par un procédé appelé « héritage ». Exactement comme un enfant qui peut hériter de certaines caractéristiques de ses parents, puis à son tour les transmettre à ses enfants, certains styles CSS « cascadent » quand ils sont imbriqués dans d'autres styles.

<div style="margin-left: 250px; margin-right: 200px;

line-height: 180%">...</div>

Les divisions de page (<div>) sont une part très importante de CSS et nous les étudierons plus en détail la prochaine fois.

Le contraste

Contrairement à une page imprimée que vous lisez par la réflexion de la lumière, la page sur un écran d'ordinateur est lumineuse. La différence de luminosité entre le texte noir et la page blanche est d'une amplitude beaucoup plus grande sur un écran que sur une page imprimée. Quand on lit de grandes zones de texte noir sur fond blanc, c'est un peu comme quand on se promène sous un grand soleil sans lunettes noires. On finit peut-être par se protéger les yeux en mettant sa main en visière, mais par défaut on a plutôt tendance à plisser des yeux et à se sentir mal à l'aise sans vraiment savoir pourquoi.

Réduire le contraste du texte des pages web permet une lecture plus confortable et moins stressante. Cela dit, si vous diminuez trop le contraste, vous commencez à rendre les choses difficiles pour les gens ayant une faible vision.

Dans un article comme celui-ci (NdT: la page originale de l'auteur) où il y a beaucoup de texte à lire et où le lecteur est amené à rester quelque temps devant son écran, il est important d'offrir un environnement aussi confortable que possible. J'ai donc utilisé une teinte de fond légère et des couleurs douces.

Fiche technique

  • Article original : CSS from the Ground Up - 4
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Valentin
  • Date de traduction : mai 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (épisode 5)

Par Joe Gillespie

Cet article est le cinquième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Cinquième étape : des listes à gogo

Une autre technique très courante pour mettre en forme des documents consiste à utiliser des « listes ». Elles ressemblent à des paragraphes, avec de petites choses en plus.

HTML peut nous fournir des listes de base qui ont soit des puces (listes non numérotées) <ul>...</ul>, soit des chiffres (listes numérotées) <ol>...</ol> en tête de chaque élément de la liste <li>...</li>. Chaque catégorie présente quelques options que l'on peut indiquer dans le HTML : li type="square" donne des puces carrées, li type="i" donne des chiffres romains en bas de casse.

Liste non numérotée par défaut :

  • Élément de liste non numérotée
  • Élément de liste non numérotée
  • Élément de liste non numérotée

Liste non numérotée avec puces carrées :

  • Élément de liste non numérotée
  • Élément de liste non numérotée
  • Élément de liste non numérotée

Liste numérotée par défaut :

  1. Élément de liste numérotée 1
  2. Élément de liste numérotée 2
  3. Élément de liste numérotée 3

Liste ordonnée avec chiffres romains :

  1. Élément de liste numérotée 1
  2. Élément de liste numérotée 2
  3. Élément de liste numérotée 3

Les CSS vous offrent davantage de choix et de contrôle : il suffit d'ajouter une définition pour ol ou ul à vos styles.

ol {list-style-type: lower-roman; margin: 1em 0 1em 40px }

Cela revient au même que si vous l'ajoutiez à chaque élément de liste en HTML, et vous avez tout contrôle sur les marges qui entourent l'ensemble de la liste. Les quatre valeurs 1em 0 1em 40px correspondent à haut, droite, bas et gauche, et peuvent être exprimées en ems, en pourcentages ou en pixels.

Si vous souhaitez mieux contrôler individuellement les éléments de liste, vous pouvez également leur attribuer des marges, pour avoir davantage d'espacement entre les lignes : par exemple...

ol li { margin: .5em 0 .5em 0 }

...ajoute un demi-em d'espacement au dessus et en-dessous de chaque élément de liste pour une liste numérotée. Pour une liste non numérotée, il faudrait le changer en ul li.

Mieux encore, vous pouvez utiliser vos propres graphiques comme puces.

ul { list-style-image: url(images/smiley.gif) }
ul li { margin: 1em 0 1em 0}
  • Ça, c'est génial
  • Ça aussi, vous aimerez
  • Et ça aussi bien sûr!

Et le top, une image de puce différente pour chaque élément de liste...

<li style="list-style-image:url(./IMG/22.png);
margin: 1em 0 1em 0">Des hommes</li>
<li style="list-style-image:url(./IMG/21.png);
margin: 1em 0 1em 0">Des images</li>
<li style="list-style-image:url(./IMG/20.png);
margin: 1em 0 1em 0">Des idées</li>
<li style="list-style-image:url(./IMG/19.png);
margin: 1em 0 1em 0">Des écrits</li>
  • Des hommes
  • Des images
  • Des idées
  • Des écrits

Les styles définis dans la partie « head » concernent l'ensemble de la page, ce que nous ne souhaitons pas dans le cas présent. Pour appliquer des styles séparément à des éléments de liste, il faut le faire « sur place », ou bien encore « inline ». Les définitions sont insérées entre les balises HTML <li> et </li>, dans la partie « body » de la page. Notez cependant qu'IE6 (Windows) place les icônes très près du texte. J'ai ajouté un peu d'espace supplémentaire au début de chaque ligne pour compenser, comme ceci :

&nbsp; Des hommes.

Fiche technique

  • Article original : CSS from the Ground Up -5
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : mai 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (épisode 6)

Par Joe Gillespie

Cet article est le sixième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Sixième étape : établir des liens

L'important, dans le mot « HTML », c'est la partie « HT », c'est-à-dire Hyper Texte. Sur une page, des liens qu'on ajoute à des mots, des phrases ou des images, peuvent être cliqués pour vous transporter à un autre endroit. Ces autres endroits s'appellent des « ancres ». Imaginez des bateaux immobiles sur la grande mer du Web, avec une chaîne constituée de liens qui descend jusqu'à une ancre posée au fond de la mer. Les bateaux sont ancrés à des emplacements bien précis, ce qui les rend plus faciles à repérer que s'ils dérivaient sur la mer.

Chaque page contient au moins une ancre. Celle par défaut est tout en haut de la page, mais vous pouvez ajouter d'autres ancres à n'importe quel point d'une page auquel vous souhaitez pouvoir accéder d'un simple clic.

<a href="http://www.wpdfd.com/index.htm">
Ceci est un lien vers le haut de ma page d'accueil
</a>

Vous voyez là une paire de balises <a>...</a>, avec en plus une partie href="..." dans la première balise. Il s'agit de l'adresse hypertexte de référence où vous souhaitez vous rendre.

Si vous placez une ancre à un emplacement bien précis dans une page (en fait, il faudrait la placer juste au-dessus de l'endroit où on veut atterrir), cela donne :

<a name="mon_ancre"></a>

Il s'agit donc d'une paire de balises <a></a> avec, dans notre exemple, name="mon_ancre" placé dans la balise ouvrante. Il n'y a rien entre les deux balises.

Pour accéder à cet emplacement, il faut ajouter un petit bout de code à l'extrémité du lien :

<a href="http://www.wpdfd.com/index.htm#mon_ancre">
Ceci est un lien vers une ancre de ma page d'accueil</a>

Comme vous le savez, les liens sur une page sont indiqués en les rendant visuellement différents du texte environnant. Par défaut, on souligne le texte du lien, et on le colorie en bleu. Quand vous cliquez sur un lien, il réagit visuellement en passant à la couleur rouge. Quand vous revenez ensuite à ce lien, il est passé à une autre couleur encore, le violet, pour montrer qu'il a déjà été visité.
Quiconque a déjà utilisé une page Web comprend le principe de ces conventions très rapidement.

La présentation par défaut des liens hypertextes en HTML se compose de trois états distincts.

Remarquez que le curseur change, lui aussi. Le pointeur qui était par défaut une flèche se transforme en main qui montre de l'index lorsque le curseur survole un lien.

Bien sûr, en tant que « designers », l'aspect par défaut des liens ne nous satisfait pas. Le texte souligné, cela peut être pratique mais aussi parfois très laid. Ce qu'il faut en priorité, c'est qu'un lien soit d'un aspect suffisamment différent de son environnement pour que l'on voie qu'il y a là quelque chose de particulier. Le contexte est également un facteur important. Tel ou tel texte constitue de toute évidence un « menu » de choix, qu'il soit souligné ou non. Sa mise en valeur, sa position dans la page, le fait que les mots vous invitent à vous rendre à d'autres endroits sont autant d'indices quant à sa fonction.

De la même façon, quand un mot ou un groupe de mots au sein d'un bloc de texte a un aspect différent, c'est sans doute pour une bonne raison. Cette raison pourrait être que l'on veut insister sur l'importance de cette partie, mais là encore, c'est le contexte qui donne l'indice, et aussi le fait que d'autres mots ou groupes de mots similaires présentent partout le même aspect. Tout cela ne fonctionnerait pas si chaque lien était d'une couleur différente.

Les CSS nous permettent de jouer un peu avec l'aspect des liens. Non, les liens ne sont pas obligatoirement soulignés et bleus. Tout ce qu'il y a à faire, c'est d'indiquer une définition pour « a » (les ancres).

a:link { color: #696; text-decoration: none }

Comme cette page (la page originale de J.Gillespie, NdT) présente un style de couleurs qui sort un peu du blanc et noir, j'ai changé les couleurs des liens en autre chose que le bleu/violet par défaut. De plus, text-decoration:none nous débarrasse du soulignage.

Pour qu'un lien déjà visité soit d'une couleur différente, tapez ceci :

a:visited { color: #699; text-decoration: none }

En CSS, il existe aussi un état supplémentaire appelé « hover ». Il permet de changer la couleur du texte au moment où le pointeur de la souris le survole, ce qui donne très utilement un indice supplémentaire qu'il s'agit d'un lien hypertexte.

a:hover { color: #c93; text-decoration: underline }

Vous voyez ainsi apparaître le soulignement traditionnel si vous le souhaitez, mais seulement de manière temporaire, lorsque le pointeur survole le texte.

L'état « actif » d'un lien, c'est ce que l'on voit à l'instant où on clique sur un lien. Il change généralement de couleur, et certains navigateurs font aussi apparaître une boîte autour du texte.

Les différents états des liens

Pour définir des liens qui s'appliquent à toute la page, il faut placer quelque chose comme ceci dans les définitions de style dans la partie « head » de la page :

a:link
  {color: #696;
  text-decoration: none;
  background-color: transparent }
a:visited
  { color: #699;
  text-decoration: none;
  background-color: transparent }
a:hover
  { color: #c93;
  text-decoration: underline;
  background-color: transparent }
a:active
  { color: #900;
  text-decoration: underline;
  background-color: transparent }

L'ordre des définitions de style est important ici. D'habitude, l'ordre n'a aucune importance en définitions CSS, mais ici c'est très important de placer les définitions a:hover et a:active en dernier, sinon elles risquent de ne pas fonctionner.

Voici maintenant un autre état, pas officialisé en CSS.

C'est un lien mort. Il ne fait rien de particulier. Si vous avez un lien sur une page qui ramène à cette même page, ma foi, ça ne rime pas à grand-chose de pouvoir y cliquer pour revenir au point de départ. Ce serait comme un panneau indicateur retourné sur lui-même et indiquant sa propre direction.

Il y a deux façons de gérer cela. Vous pouvez transformer le lien en titre, en le mettant davantage en valeur que le reste, ou bien vous pouvez le rendre pratiquement invisible, montrant ainsi que ce n'est pas un choix possible. On appelle cela le « grisage », et vous en reconnaîtrez le principe pour l'avoir vu en usage sur d'autres programmes de votre ordinateur.

Mais, direz-vous, pourquoi le placer là si on ne souhaite pas que les gens le choisissent ?

Eh bien, l'un des principes les plus importants dans le design d'une interface est que l'on essaie de garder pour tous les éléments la plus grande cohérence possible. Si on retire un élément d'un menu, par exemple, certains autres vont changer de place. Ce sera moins gênant pour l'utilisateur si l'interface reste clouée en place.

Enfin, l'autre élément dont nous disposons ici est la couleur de fond (background-color) derrière le texte. Les designers changent parfois la couleur de fond pour donner un effet proche du surlignage pour les états hover ou active.

Il ya encore beaucoup d'autres choses à faire avec les liens CSS, nous n'avons fait qu'effleurer la question, mais cela devrait suffire à vous permettre de démarrer. Cette page d'exemple met en application les principes que vous venez d'apprendre.

Fiche technique

  • Article original : CSS from the Ground Up -6
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : juillet 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

Par Joe Gillespie

Cet article est le septième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Septième étape : les boîtes CSS

Nous avons déjà vu que le texte dans une page Web peut être découpé en titres ou en paragraphes, et que le langage HTML prend en charge ces opérations. Nous avons également vu comment les styles par défaut peuvent être modifiés à votre convenance, en leur attribuant de nouvelles définitions de style qui remplacent celles d'origine. Maintenant, je vais me pencher sur la façon de créer vos propres définitions de style pour étendre les possibilités du HTML et faire des mises en page plus intéressantes.

La partie « body » d'une page contient tout ce qui est visible ; cependant, comme je l'ai montré à l'étape 3, il est possible de découper cette partie en divisions plus petites et qui ont leurs propres styles. Ces divisions peuvent ne contenir qu'un simple caractère, ou au contraire inclure de grands pans rectangulaires de la page. Tout ce que nous avons à faire, c'est d'entourer la zone que nous voulons styler d'une paire de balises <div>...</div>. Chacune de ces divisions est comme une mini-page, et on les appelle souvent « boîtes CSS ». Les boîtes CSS sont les matériaux de base que l'on utilise pour construire des mises en page pour le Web, et je vais m'attarder sur la façon dont elles fonctionnent parce que c'est très important.

Les boîtes CSS peuvent avoir une hauteur et une largeur, une couleur de fond ou même une image de fond que l'on peut faire répéter pour créer un effet graphique. Par défaut, une boîte CSS s'étend de la marge gauche à la marge droite du corps de la page. Si vous n'avez pas indiqué de marge pour la partie « body », elle prendra donc toute la largeur de la fenêtre du navigateur. Si vous n'indiquez pas de hauteur pour une boîte CSS, elle n'en aura pas. Si vous y placez du texte, elle s'étendra verticalement pour contenir ce texte (ou cette image).

Pour éloigner du texte du bord d'une boîte, on peut ajouter du remplissage (« padding ») comme ceci :

les 4 paddings

Mieux vaut faire très attention avec le remplissage, parce que son interprétation dans Internet Explorer est très différente de celle de tous les autres navigateurs. Contrairement à notre illustration, IE place le remplissage à l'intérieur de la boîte, de telle sorte que sa hauteur et sa largeur ne changent pas. Tous les autres navigateurs placent le remplissage en-dehors de la boîte, ajoutant ainsi à sa largeur et à sa hauteur. Donc la taille de votre boîte peut varier selon le navigateur avec lequel vous voyez la page, ce qui peut avoir des conséquences désastreuses si vous êtes tenus à des mesures précises au pixel près.

Après le remplissage, vous pouvez placer une bordure (« border ») :

Les bordures existent dans plusieurs styles différents, et vous pouvez traiter chacun des quatre côtés séparément pour ce qui concerne l'épaisseur, le style et la couleur. Leur aspect varie un peu selon les navigateurs, mais voici à quoi elles ressemblent dans Mozilla :

styles de bordures

L'épaisseur de la bordure augmente d'autant la taille d'une boîte.

Et pour séparer les boîtes les unes des autres, vous pouvez leur donner des marges (« margins »).

Il est fréquent de confondre les marges et le remplissage, surtout que ce qu'on appelle couramment la « marge » d'une page dans un livre ou une page Web est en fait du « remplissage » dans la mesure où c'est un espace qui ne peut sortir de la page, il est forcément à l'intérieur. Mais souvenez-vous que c'est un cas particulier. Pour le « body » d'une page Web, la marge va des côtés vers l'intérieur, tandis que toutes les autres marges CSS vont vers l'extérieur.

Le positionnement absolu

En plus d'avoir une hauteur et une largeur, les boîtes CSS peuvent être placées à n'importe quel emplacement sur la page en indiquant position: absolute;
Le principe du positionnement absolu est facile à comprendre, il correspond à la façon de voir les choses dans la vie de tous les jours. Par exemple, votre maison peut être située à 50 mètres de la Rue du Nord et à 100 mètres de la Rue de l'Est.

La façon la plus courante de donner une position à une boîte est tout simplement d'indiquer quelque chose comme top:50px; left:100px, mais on n'est pas obligé d'utiliser top et left, cela peut aussi bien être top et right, bottom et left ou bottom et right.

Voici quelques boîtes CSS avec différents styles, chacune affichant sa définition de style. Les possibilités de combinaisons sont infinies.

Quand les boîtes sont placées à des coordonnées absolues, avec des largeurs et hauteurs bien précisées, cela ressemble beaucoup à un travail de collage de coupures de presse ou de photos dans un cahier de souvenirs. Le problème, c'est que les cahiers conservent toujours la même taille, et pas les pages Web.

Le positionnement relatif

Si vous cherchez à décrire la position de la maison du voisin d'à-côté, vous pouvez dire qu'elle est à 70m de la rue du Nord et à 100m de la rue de l'Est, mais vous pouvez aussi dire qu'elle est à 5m, juste après la vôtre. Le positionnement relatif part du principe que les boîtes CSS sont placées l'une après l'autre. La première boîte est celle du dessus, la suivante est en-dessous, et la suivante encore en-dessous. De fait, elles flottent de haut en bas, à partir du haut de la page. Ce n'est peut-être pas très réaliste, mais imaginez une piscine couverte, avec à l'intérieur toute une pile de matelas gonflables. Le premier flotterait jusqu'à la surface, le suivant flotterait vers le haut et se retrouverait coincé sous celui du dessus, et ainsi de suite.

Pour obtenir que les boîtes CSS soient côte-à-côte au lieu de l'une au-dessous de l'autre, il faut leur dire de flotter à gauche ou à droite : float:left; ou float:right;. Tout comme nos matelas gonflables si la piscine est suffisamment large, elles se tiendront côte-à-côte, tant qu'il y aura de l'espace disponible. Puis elles glisseront à l'étage inférieur. Mieux vaut éviter cette situation, en vous assurant que les largeurs cumulées de toute une rangée de boîtes n'excèdent pas la largeur de la page. On peut le faire en précisant la largeur en pixels, mais en maintenant le total en-dessous de la largeur minimum d'un navigateur. On peut aussi utiliser les pourcentages, à condition de vérifier que la somme des pourcentages arrive bien à 100, ou mieux, un peu moins. Dans un tel contexte de positionnement relatif, évitez de mélanger pixels et pourcentages, sans quoi les résultats sont imprévisibles.

Ces exemples de boîtes flottantes montrent le comportement de boîtes positionnées de manière relative, en colonnes simples ou multiples.

Fiche technique

  • Article original : CSS from the Ground Up -7
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : juillet 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (épisode 8)

Par Joe Gillespie

Cet article est le huitième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Huitième étape : des div sur mesure

Qu'est-ce qu'une id ?

Lorsque vous créez des boîtes CSS avec des définitions personnalisées, il n'existe pas d'éléments HTML pouvant y faire appel. Il vous faut les inventer.

Comme il y aura sans doute plusieurs, voire beaucoup de boîtes CSS (des « div ») dans une page donnée, il faut leur trouver des noms. Pour ce faire, on leur attribue des « identités », qu'on appelle id en abrégé. Une id fournit à une boîte CSS une identité qui lui est propre, qui vous permet à vous de bien la repérer et au navigateur de l'afficher correctement.

Prenons un exemple simple : vous voulez diviser une page en trois parties horizontales. Un « en-tête » en haut présente un logo et les liens de navigation. La partie du milieu contient le texte et les images. Tout en bas, vous pouvez aussi avoir un « pied de page » donnant des informations de copyright, et peut-être une répétition de la navigation du haut de page.

Dans cet exemple, plus précisément, vous trouverez cinq boîtes horizontales, les deux supplémentaires servant pour le logo et la barre de navigation, entre l'en-tête et la zone de texte.

Remarquez que la colonne de droite est plus étroite que celle de gauche, ce qui permet de compenser visuellement l'espace supplémentaire dû à l'aspect crénelé de la partie droite du texte, sans quoi celui-ci paraîtrait décentré.

Dans les définitions de style, nous collons un signe dièse (#) devant le nom que nous voulons donner à la boîte, ce qui en fait une « identité ».

#en-tete {...}
#navigation {...}
#logo {...}
#milieu {...}
#pied-de-page {...}

Puis nous devons lier les définitions aux boîtes CSS elles-mêmes, tout simplement en renvoyant à leurs identités (id) comme ceci :

<div id="en-tete">...</div>
<div id="navigation">...</div>
<div id="logo">...</div>
<div id="milieu">...</div>
<div id="pied-de-page">...</div>

Si l'on a déjà indiqué, par exemple, une police d'écriture dans la déclaration de styles pour la partie body, alors nos boîtes vont « hériter » de ces styles. Mais toute définition de style ajoutée aux définitions des boîtes prendra le pas sur la définition du body, qui est plus large. C'est le principe même de la « cascade ».

Qu'est-ce qu'une class ?

Vous aurez parfois besoin d'utiliser la même boîte plusieurs fois sur une même page. Imaginons que vous voulez séparer la partie du milieu en deux boîtes distinctes, ou plus. Dans ce cas, il vous faut une boîte « réutilisable » et non pas unique. Une boîte réutilisable s'appelle une class. Tout comme on a des « classes » de fleurs ou d'insectes, une class désigne une même boîte mais avec un contenu différent. Pour montrer que nous voulons une class réutilisable au lieu d'une id unique, nous utilisons le point (.) au lieu du signe dièse.

.milieu {} peut désormais être utilisé aussi souvent qu'on le veut, et sur la div elle-même, on précise :

<div class="milieu">...</div>
<div class="milieu">...</div>
<div class="milieu">...</div>

Qu'est-ce qu'un span ?

Les class, contrairement aux id, peuvent s'appliquer au niveau du texte. Si on veut simplement mettre quelques mots en rouge, on peut créer une class spéciale, appelons-la .texterouge :

.texterouge { #cOO }

<span class="texterouge">Ce texte est rouge!</span>

Au lieu d'entourer le texte que l'on veut en rouge d'un <div>...</div>, on utilise <span>...</span>. On dit que ce style est inline, c'est-à-dire en ligne, parce qu'il s'applique à un morceau de texte lui-même déjà contenu dans un <div>...</div>.

Utilisez <span>...</span> dès que vous voulez marquer sur du texte une variation par rapport aux indications générales. Il peut s'agir de couleur, de police d'écriture, de taille, de poids, etc.

Donc, en CSS, il y a des éléments dits block qui sont constitués de boîtes rectangulaires, dotées soit d'id uniques, soit de class réutilisables. Et nous avons aussi des éléments dits inline, qui traitent le texte au caractère près.

On commence à aborder les choses sérieuses !

Fiche technique

  • Article original : CSS from the Ground Up -8
  • Auteur : Joe Gillespie
  • Traduction : Frédéric Chotard
  • Date de traduction : septembre 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (épisode 9)

Par Joe Gillespie

Cet article est le neuvième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Neuvième étape : on met tout ensemble

Dès qu'on aborde des pages Web un peu élaborées, on utilise un mélange d'id et de class, voire de positionnement absolu et relatif. Retournons à notre page toute simple de la huitième étape, celle en cinq parties : peut-être pourrait-on avoir plusieurs colonnes dans la partie du milieu. Cela revient à utiliser la propriété de flottement (float), et je vais choisir float:left pour m'en tenir au plus simple.

En général, sur beaucoup de pages Web, la colonne de gauche contient les menus, ce qui veut dire qu'elle peut être assez étroite.

.col-gauche {}

La colonne du mileu contiendra le texte principal.

.col-milieu {}

Et tout à droite, nous allons placer une autre colonne étroite, pour des liens de référence ou de la publicité.

.col-droite {}

La taille de chaque colonne est indiquée en pourcentage, pour qu'elle soit fluide et s'adapte à la largeur de la page.

Vous noterez que j'utilise des classes (class) pour ces colonnes, parce que je pourrais souhaiter les réutiliser plus bas sur ma page.

Dans cet exemple, on remplace la simple partie .milieu par trois colonnes flottant à gauche.

<div class="col-gauche">...</div>
<div class="col-milieu">...</div>
<div class="col-droite">...</div>
Présentation avec trois colonnes

Voilà qui ouvre des perspectives de mise en page beaucoup plus intéressantes.

Ne laissez pas de div complètement vides, même si elles ne doivent contenir que du « blanc ». Placez-y un espace insécable &nbsp;.

Fiche technique

  • Article original : CSS from the Ground Up -9
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : septembre 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (10ème épisode)

Par Joe Gillespie

Cet article est le dixième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Doctypes et validation

Nous voilà arrivés à la dixième leçon de « On reprend tout à zéro », et il faut que je vous avoue quelque chose. Tout ce que je vous ai montré jusqu'ici, le balisage, les pages d'exemples, eh bien tout ceci est faux ! Bon, en fait, ça va sans doute fonctionner correctement (sauf si vous utilisez un navigateur trop ancien), mais si vous testez vos pages avec un vérificateur de syntaxe, ou bien si vous les soumettez à un quelconque programme de validation, elles ne passeront pas l'épreuve.

Vous vous demandez peut-être ce qu'est un programme de validation.

Vous connaissez sûrement les correcteurs d'orthographe. Votre programme de traitement de texte en contient vraisemblablement un. Ils servent à comparer les mots que vous avez tapés avec ceux de leur dictionnaire intégré, et vous avertissent s'ils ne trouvent pas de concordance. Peut-être le mot n'est-il pas dans le dictionnaire, mais peut-être aussi ne l'avez-vous pas tapé correctement. Dans les traitements de texte les plus élaborés, votre texte peut également subir une vérification grammaticale, et si vous tapez une phrase qui ne contient pas de verbe ou qui contient trop d'occurences du mot « et », ils vous harcèleront sans arrêt.

Pour qu'un correcteur d'orthographe ou de grammaire puisse faire son travail, il doit savoir quelle langue vous utilisez. Un correcteur d'anglais britannique est déjà différent d'un correcteur d'anglais américain, alors que dire de ceux qui utilisent une toute autre langue que l'anglais ?

De même qu'on corrige son anglais, son français, ou toute autre langue, on peut (et on doit !) corriger également son HTML et son CSS. Si votre anglais contient une erreur, les gens penseront qu'il s'agit d'une coquille, mais comprendront ce que vous voulez dire, il n'y aura pas grand-mal. En revanche, une petite erreur en HTML ou en CSS, c'est une toute autre histoire. Quelque chose d'aussi insignifiant en apparence qu'une virgule ou un guillemet mal placés peut faire toute la différence entre une page qui fonctionne ou non : tout dépend du type d'erreur et du navigateur qui essaie de comprendre ce qui se passe. Il est très recommandé de « vérifier l'orthographe » de votre HTML comme de votre CSS avec un « correcteur de syntaxe » ou un « validateur ».

L'un des grands avantages dont vous bénéficiez si vous utilisez un éditeur HTML de bonne qualité, c'est qu'il contient un correcteur de syntaxe intégré. Vous ne trouverez pas cela avec de simples éditeurs de texte polyvalents. Si vous avez un éditeur HTML comme HomeSite ou BBEdit, ou bien un éditeur WYSIWYG tel que Dreamweaver ou GoLive, vous pourrez vérifier votre balisage et si possible trouver des suggestions pour en corriger les erreurs. Si vous ne possédez pas de tels programmes, vous pouvez utiliser les validateurs en ligne offerts par le W3C : le validateur HTML et le validateur CSS du W3C, où vous pouvez tout simplement envoyer vos fichiers et recevoir un rapport immédiat indiquant la liste exhaustive de vos erreurs, sauf si vous n'en avez commis aucune !

Bien entendu, le programme de correction doit d'abord savoir quel « langue » vous utilisez pour votre balisage : il y a différentes « gammes » de HTML. Jusqu'ici, tous les exemples que j'ai montrés sont écrits en HTML 4.01 : il s'agit de la version actuelle, et c'est la plus répandue. Mais il y a différentes versions de HTML 4.01 : « Strict », « Transitional » et « FrameSet ».

Le Strict est constitué d'un ensemble de règles qui définissent très strictement ce que l'on peut faire ou ne pas faire en HTML.

Le Transitional est un peu plus compréhensif, et vous permet d'utiliser un HTML un peu plus ancien ainsi que quelques particularités propres à certains navigateurs.

Le Frame Set n'est plus beaucoup utilisé de nos jours. Nous n'avons d'ailleurs pas évoqué les « frames » (cadres) dans cette série de cours, dans la mesure où ils sont largement passé de mode depuis l'arrivée des CSS.

La plupart des gens se contentent très bien du « Transitional » parce qu'il leur laisse un peu de souplesse, mais il y en a d'autres qui aiment que tout soit bien net et règlementaire et qui préfèrent utiliser le « Strict ».

Pour que le navigateur sache quel langage vous utilisez pour votre balisage, et dans quelle version, placez une déclaration de Doctype tout en haut de la page, au-dessus de la première balise <html>. En voici un exemple :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

Je ne vais pas analyser tout de suite tout ce que cela signifie ; contentez-vous de savoir qu'avec ce charabia au sommet de votre page, le vérificateur de syntaxe ou le validateur sera capable de faire correctement son travail. Il sait désormais quels sont les standards que vous voulez appliquer à votre page, et va pouvoir la juger en fonction de ceux-ci.

Dès lors que j'ai placé un Doctype, je peux passer mes pages au vérificateur de syntaxe de mon éditeur HTML et m'assurer qu'elles sont impeccables. Maintenant qu'on a réglé ce petit détail annexe, revenons au style de notre page !

Fiche technique

  • Article original : CSS from the Ground Up -10
  • Auteur : Joe Gillespie
  • Traduction : Frédéric Chotard
  • Date de traduction : octobre 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (11ème épisode)

Par Joe Gillespie

Cet article est le onzième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Jusqu'ici, tous les styles que j'ai utilisés ont été intégrés à la section <head> des pages. De cette façon, il est facile de regarder le code-source de la page et de voir ce qui s'y passe. Tout est bien mis ensemble au même endroit.

Toutefois, il est très rare que des pages individuelles soient fabriquées à l'unité : il est beaucoup plus probable qu'on trouvera, dans un site Web donné, tout un ensemble de pages dont l'aspect est similaire.

Au lieu de reproduire une déclaration de styles sur chaque page, il vaut bien mieux n'avoir qu'une seule feuille de style et faire en sorte que chaque page y renvoie individuellement. Du coup, si vous voulez changer la couleur de fond de toutes les pages de votre site, ou bien modifier la couleur ou la taille des caractères, il n'y aura qu'à changer la feuille de style principale. En fait, on peut changer totalement l'aspect de tout un site en appliquant juste quelques modifications à un seul et unique fichier.

Allez donc jeter un oeil sur http://www.csszengarden.com/ pour voir ce principe en action. Différents designers ont fourni leurs propres feuilles de style pour habiller le contenu d'une même page, démontrant ainsi de manière admirable comment un seul et même squelette peut recevoir différentes « peaux » qui changent sa personnalité du tout au tout. Pour utiliser une feuille de style externe, tout ce que nous avons à faire consiste à intégrer ce type de lien dans notre page :

<link rel="stylesheet"
href="styles_de_base.css"
type="text/css"
media="screen">

Cela indique au navigateur qu'il doit chercher les indications de style dans un fichier nommé « styles_de_base.css ». On précise aussi qu'il s'agit d'un simple fichier texte ( d'où type="text/css" ) et que les styles sont prévus pour un affichage sur écran ( media="screen" )

Les feuilles de style ne sont pas limitées à l'affichage sur des écrans d'ordinateur : vous pouvez produire des feuilles de style pour d'autres supports comme l'impression, la projection ou même le braille. Quand on y réfléchit bien, une feuille de papier d'imprimante n'a pas du tout la même taille ni la même forme qu'un écran d'ordinateur, et personne n'aura envie de gâcher sa très chère encre à imprimer de vastes zones colorées alors que tout ce qu'on veut, c'est conserver comme référence un texte noir sur blanc. Une feuille de style pour l'impression doit donc réduire la largeur de la page pour qu'elle corresponde à une feuille de papier, et contrairement à la feuille de style « écran », les tailles de caractères doivent être indiquées en points ( pt ). Les couleurs doivent être simplifiées, voire complètement abandonnées. Enfin, tout ce qui restera à faire sera d'ajouter un second lien dans la partie <head> juste après celui pour l'écran ( screen ).

<link rel="stylesheet"
href="styles_pour_impression.css"
type="text/css"
media="print">

Si vous vous contentez amplement de la même feuille de style pour l'écran comme pour l'impression, alors vous pouvez utiliser ce lien :

<link rel="stylesheet"
href="styles.css"
type="text/css"
media="all">

Bien que la plupart de mes feuilles de style finissent toujours par se retrouver enregistrées à part, je démarre généralement avec une feuille de style interne pour les premières étapes du design. Une fois satisfait de l'aspect général, je coupe et je colle les styles dans un nouveau fichier, et je les remplace par un lien.

Fiche technique

  • Article original : CSS from the Ground Up -11
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : octobre 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (12ème épisode)

Par Joe Gillespie

Cet article est le douzième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Je sais bien qu'on utilise des tableaux pour réaliser des mises en page depuis la préhistoire du Web, mais je pense avoir démontré dans ce feuilleton que les mises en page par CSS offrent davantage de possibilités et de souplesse. Les tableaux sont faits pour présenter des données tabulaires, comme on le ferait avec les feuilles de calcul qu'on utilise pour organiser des chiffres ou des mots en rangs et en colonnes.

Autrefois, avec les anciens navigateurs, il était possible de changer l'aspect des tableaux et de leurs cellules en utilisant les différentes propriétés de tableaux : couleurs de fond, images de fond, etc. Beaucoup de ces caractéristiques sont désormais dépassées et ne sont plus valides ; même s'il est encore possible qu'elles fonctionnent, on ne peut plus compter sur elles. D'ailleurs, on n'a jamais vraiment pu compter dessus. Quand on cherchait à placer une image de fond pour un tableau sous Netscape 4 ou une version antérieure, celle-ci apparaissait individuellement dans chacune des cellules, un peu comme quand on regarde à travers un kaléidoscope, ce qui rendait le tout aussi pénible à faire qu'inutile.

Avant, on pouvait sans problème indiquer une hauteur de tableau en pixels, ou encore en pourcentage de la hauteur de la fenêtre, mais ce n'est plus possible. Les tableaux fixent leur propre hauteur en fonction de leur contenu.

La gestion du style des tableaux avec les CSS peut se révéler un peu délicate, et il est difficile de tout prévoir. On peut construire sa propre structure de tableau en CSS à l'aide de display:table; et de display:table-cell;, en considérant que chaque cellule constitue une boîte (div) séparée, mais dans la plupart des cas, il est plus simple de se contenter de fournir les définitions de style pour les éléments HTML du tableau : table, tr, td, th, etc.

tr représente une rangée de tableau, c'est-à-dire une rangée horizontale de cellules. td est une division de rangée de tableau. On peut le voir comme une colonne, mais il ne se comporte pas comme une colonne, et on ne peut pas indiquer une couleur de fond ni un style d'écriture propre à une colonne.

Les tableaux héritent de certains styles des divs auxquelles ils appartiennent, mais pas de tous. Si la partie body de votre page a pour caractéristiques font-family: verdana, arial, sans-serif style et color:#009, le tableau héritera de celles-ci, mais pas de la taille du texte ni de son alignement. Il y a également une hiérarchie. Toute règle s'appliquant à un td prendra le pas sur celle du tr, qui elle-même passera avant toute règle générale de style imposée pour l'élément table, c'est-à-dire le tableau. Vous pouvez tourner ceci à votre avantage. Si vous choisissez le noir comme couleur de fond de tableau, et le blanc comme couleur de fond du td, et si vous donnez au tableau un écartement des cellules de 2 pixels (cellspacing="2"), vous obtiendrez un tableau avec des cellules blanches séparées par une bordure noire de 2 pixels.

1 | 2 | 3 | 4
1 | 2 | 3 | 4
1 | 2 | 3 | 4
Le tableau 1 ci-dessus, plus subtil, présente une couleur de fond de tableau transparente, et une légère teinte de couleur de fond est appliquée aux td.

Bien entendu, vous avez également accès à tous les styles CSS pour les bordures, ce qui signifie que vous n'êtes pas prisonnier des horribles bordures de tableau par défaut en HTML. Vous pouvez également jouer avec les couleurs ou les aspects des bordures pour n'afficher que des lignes verticales ou des horizontales, qui seront pleines, pointillées, hachurées ou autres.

1 | 2 | 3 | 4
1 | 2 | 3 | 4
1 | 2 | 3 | 4
Tableau 2. Selon les données, on veut parfois insister sur les rangées horizontales, ou bien sur les colonnes verticales comme ci-dessus.

Titre 1 | Titre 2 | Titre 3 | Titre 4
1 | 2 | 3 | 4
1 | 2 | 3 | 4
Tableau 3. Ici un effet de relief en 3D est créé en modifiant les couleurs de bordures. L'en-tête de tableau th reçoit une couleur de fond plus sombre.

Une autre idée intéressante consiste à attribuer aux tr des images de fond en dégradé de couleur.

Si vous créez une petite image suffisamment haute pour remplir la cellule tout en restant très étroite, disons 8 pixels de large, il sera possible de la répéter horizontalement avec background-repeat: repeat-x, ce qui est plus fin et élégant que des bordures.

Cette petite image (227 octets) peut être répétée horizontalement...

Rangée 1 | 2 | 3 | 4
Rangée 1 | 2 | 3 | 4
Rangée 1 | 2 | 3 | 4
Rangée 1 | 2 | 3 | 4
Tableau 4. J'ai utilisé un dégradé légèrement plus sombre pour les en-têtes de rangées, et j'ai ajouté une bordure gauche gris pâle pour séparer les colonnes.

Si vous voulez appliquer aux cellules individuelles un style différent de l'ensemble du tableau, vous pouvez le faire en utilisant des définitions de style « en ligne » adjointes aux balises <td> appropriées.

<td style="background-color: #f00">cellule 1</td>

1 | 2 | 3 | 4
 | 2 | 3 | 4
1 | 2 | 3
1 | 2 | 3 | 4
Tableau 5. Bon d'accord, je suis un peu trop fan de Mondrian, mais l'important c'est de voir qu'on peut appliquer à volonté des styles sur des cellules individuelles !

Cette approche, en revanche, a le désavantage de ne pas permettre l'utilisation d'une feuille de style externe. Tout est gravé dans le code même de la page ; mais on peut se l'accorder, de manière exceptionnelle. Une façon plus adroite de styler rangées et colonnes consiste à les placer au sein de leurs propres div et à les nommer ainsi :

#colonne1 td { ... }
#colonne2 td { ... }

Avec cette méthode, vous bénéficiez d'un certain contrôle sans pour autant devoir recourir à une construction de tableau par div individuelles (ce qui reste une excellente solution, si vous en avez le temps et la patience).

Je n'ai pas placé toutes les déclarations de style dans la page, il y en a trop, mais un coup d'oeil sur le code-source vous permettra de comprendre ce qui se passe.

De nombreuses possibilités vous sauteront à l'esprit quand vous commencerez à styler vos tableaux. Mais non, ce n'est pas obligatoirement barbant de faire des tableaux !

Le mois prochain, nous verrons comment styler des formulaires, ainsi que quelques autres petits détails.

Épisode 13 »

Fiche technique

  • Article original : CSS from the Ground Up -12
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : novembre 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

CSS : on reprend tout à zéro ! (13ème épisode)

Par Joe Gillespie

Cet article est le treizième d'une série qui en compte 15. Chaque épisode sera publié bimensuellement dans nos pages.

Pour de nombreux designers, le style des formulaires dans les pages Web ne constitue pas une grande priorité. Les formulaires sont généralement laissés « tels quels », et pour de bonnes raisons d'ailleurs.

  1. Les conventions qui sont utilisées par défaut pour les formulaires fonctionnent assez bien en l'état.
  2. Si un formulaire n'a pas l'aspect attendu, les lecteurs pourraient ne pas s'y retrouver.
  3. Le style des formulaires peut devenir très différent d'un navigateur à l'autre, selon l'interprétation qu'ils en font.

Voyons tout cela de plus près.

« Les conventions qui sont utilisées par défaut pour les formulaires fonctionnent assez bien en l'état. »

Bon, peut-être. Pourtant on trouve encore un peu partout beaucoup de tableaux mal conçus, que ce soit sur papier ou sur le Web.

Moi en tous cas, je déteste remplir des formulaires, et je sais que je ne suis pas seul à réagir ainsi.

Mais les formulaires sont bien pratiques pour récolter de l'information, d'autant qu'ils la récoltent d'une manière qui en rend l'exploitation assez facile. Alors, quelle est l'erreur commise par les « designers » de formulaires ?

Le premier gros écueil apparaît lorsque le formulaire semble compliqué. L'utilisateur est intimidé et se place en position défensive.

Et puis, on nous pose des questions qui peuvent paraître soit inutiles, soit indiscrètes. Pourquoi voulez-vous absolument connaître ma date de naissance ?

L'aspect compliqué est une question de mise en forme. On peut donner à un formulaire une apparence simple en le présentant de manière propre et ordonnée. La première chose dont on doit s'assurer, c'est de bien contrôler les tailles de police pour ne pas les laisser démolir la mise en page.

La taille et la position des légendes ou des textes explicatifs doivent aussi être réfléchies. Le mieux est de les placer soit au-dessus ou en dessous des champs de saisie, soit sur la droite. Si vous tenez vraiment à mettre des textes sur la gauche, utilisez align: right; pour éviter de vous retrouver avec d'énormes trous qui déconnectent visuellement le texte de son champ, et augmentent la complexité visuelle de la mise en page. Essayez également de ne pas avoir trop de tailles différentes pour vos champs de saisie, et ne remplissez pas les espaces vides à tout prix. Si le champ du code postal est plus court que les autres champs d'adresse, ce n'est pas un problème : ne placez pas pour autant différentes tailles de champs sur une même ligne horizontale juste pour gagner de l'espace.

Sur une page Web, on n'a pas besoin de gagner de l'espace. Choisissez intelligemment les tailles de vos champs de saisie. Alignez-les verticalement. Gardez-les propres et dégagés.

Ci-dessus, un formulaire qui semble compliqué. Il y a deux axes verticaux, et le déplacement du regard est perturbé par la nécessité de sauter horizontalement et verticalement pour trouver le champ suivant.

Voici un design plus simple, avec un seul axe vertical en plein milieu, ce qui n'interrompt pas le déplacement du regard.

L'avantage par rapport à un formulaire papier, c'est qu'un formulaire Web masque tout ce qui n'est pas immédiatement visible dans la fenêtre du navigateur, évitant ainsi de noyer le visiteur sous la masse. Néanmoins, un formulaire très long sur une seule page exigera de nombreux défilements verticaux, ce qui peut être encore pire. Mieux vaut diviser les formulaires longs sur toute une série de pages, à condition toutefois de penser à permettre aux utilisateurs de revenir en arrière s'ils veulent modifier quelque chose.

« Si un formulaire n'a pas l'aspect attendu, les lecteurs pourraient ne pas s'y retrouver. »

Il est clair qu'on ne peut pas « s'éclater » dans le design de formulaires. Il faut bien que le lecteur comprenne la fonction d'un champ de saisie de texte, comme pour une fenêtre pop-up ou un bouton d'envoi. Ça ne signifie pas pour autant que nous sommes condamnés au texte noir sur fond blanc (encore que certains navigateurs n'acceptent rien d'autre !)

Ce serait une erreur d'assimiler un champ de saisie à du texte ordinaire, la fenêtre doit avoir son apparence propre, tout en indiquant sa fonction.

Les éléments que l'on peut styler sont input, textarea et select, mais attention : tout style attribué à l'élément input affectera non seulement le champ de saisie de texte, mais également les autres outils de saisie que sont les boutons radio, les cases à cocher, ainsi que les boutons « Envoyer » et « Effacer ».

On peut sans risque jouer sur les styles font-family et font-size des polices. La couleur du texte (text-color) peut varier si on le souhaite. Pour la couleur de fond (background-color), c'est plus discutable. Si elle est d'une teinte plus pâle que celle de la page, c'est acceptable, et cela peut rendre l'aspect du formulaire moins agressif.

Si on change le contour d'un champ de saisie de données (« input »), cela modifie également le contour du bouton d'envoi, qui du coup peut se mettre à ressembler à n'importe quelle zone de texte si on n'y prend garde. Pour éviter cela, il faut donc « envelopper » le champ de saisie dans une div qui lui sera propre, et se contenter d'appliquer des styles sur #saisie input comme ci-dessous :

#saisie { }

#saisie input
        {
        color: #633;
        font-size: 10px;
        background-color: #ebebd9;
        padding: 3px;
        border: double 3px orange
        }

NdT : les éléments input et textarea ne peuvent être traduits, car il s'agit de code HTML. Rappelons que input fait référence à de la saisie de données de formulaire (un nom, une date, un chiffre...), tandis que textarea permet de saisir des commentaires, des remarques ou autres textes longs.

Si maintenant vous voulez qu'un champ textarea ressemble à un champ input, vous pouvez faire ceci :

#saisie input, #saisie textarea
        {
        color: #633;
        font-size: 10px;
        background-color: #ebebd9;
        padding: 3px;
        border: double 3px orange
        }

Quant à l'élément select (il s'agit des listes déroulantes), son rendu varie d'un navigateur et d'une plateforme à l'autre. Tout ce que nous pouvons faire, c'est fixer une taille et une famille de police. De toute manière, vous ne pouvez généralement avoir aucune idée de l'aspect final, une fois qu'ils auront été cliqués.

« Le style des formulaires peut devenir très différent d'un navigateur à l'autre. »

La meilleure des preuves réside dans ces quelques copies d'écran.

Les mêmes styles interprétés sous Explorer (Windows), Mozilla, Safari (Mac) et Opera montrent quelle variété on peut trouver. Je reviendrai dans le prochain épisode sur les différences entre les interprétations des navigateurs.

L'important ici est que nous ne cherchons pas à enjoliver les formulaires. Nous essayons de les rendre plus faciles à utiliser et moins impressionnants grâce à une présentation visuelle réfléchie.

On peut encore faciliter davantage la vie de l'utilisateur avec des scripts de validation de formulaires qui sont bien utiles, mais c'est une tout autre histoire, dans laquelle je ne compte pas m'engager tout de suite.

Episode 14

Fiche technique

  • Article original : CSS from the Ground Up -13
  • Auteur : Joe Gillespie
  • Date de parution : 2004
  • Traduction : Sylvain Lelièvre, Frédéric Chotard
  • Date de traduction : décembre 2005
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

Définir des tailles de police dynamiques cohérentes avec CSS

Par Robert Nyman

Pour un développeur de sites web, il est naturel d'offrir à ses visiteurs la possibilité d'ajuster la taille du texte à loisir, quel que soit leur navigateur. J'aimerais vous présenter ici la manière la plus cohérente que j'ai trouvé pour y parvenir en CSS.

Le problème

Comme bien souvent, le problème vient des navigateurs. En effet, Internet Explorer ne permet pas à l'utilisateur de redimensionner du texte dont la taille de police est définie en pixels (px). Les unités relatives (em, pourcentages, etc.) ne sont pas affectées. Ce défaut n'a pas été corrigé dans IE7, bien que cette version permette de zoomer sur l'ensemble de la page (même si ce n'est pas du tout la même chose).

C'est un vrai problème, parce que la plupart des mises en page et des résultats attendus se mesurent en pixels, et qu'il y a plus d'une façon d'y arriver.

La solution que j'utilise

Tout d'abord, il faut choisir une unité de mesure pour les tailles de police. J'ai opté pour l'em, parce qu'elle me semble la plus stable et la mieux implémentée. Appliquer une taille d'1 em revient à donner à un élément la même taille que son parent.

Commençons par le commencement.

La taille de texte par défaut dans la plupart des navigateurs (j'aimerais pouvoir affirmer « dans tous » mais on ne sait jamais) est de 16 px, et nous allons partir de là. Pour être sûrs que toutes les tailles de police héritent correctement de cette valeur, définissons pour commencer une taille de 100% pour l'élément HTML.

HTML{
    font-size: 100%;
}

L'étape suivante consiste à déterminer la taille de texte par défaut pour l'ensemble du site, celle qui sera appliquée à la majorité du texte. Elle nous fournira également un bon point de départ pour calculer la taille des autres éléments. Prenons une page web pour laquelle nous désirons une taille de texte de 10px. Si nous divisons cette taille par celle précédemment appliquée par le navigateur, cela donne 10 / 16 = 0,625. Nous utiliserons donc cette valeur, en em, sur la balise body.

body{
    font: 0.625em/1em Verdana, Geneva, Arial, Helvetica, sans-serif;
}

Avec cette règle, le texte de la page fera 10px sauf si nous en décidons autrement. Par exemple, si vous voulez changer la taille des différents niveaux de titres (ce qui est assez probable), le calcul s'effectue maintenant à partir de la valeur définie pour body.

Grâce aux règles précédentes, définir pour un élément une taille d'1em le fera s'afficher à 10px. Si vous souhaitez que les éléments h1 fassent 17px, il faut calculer leur taille comme ceci : 17 / 10 = 1,7. Le code pour la taille des h1 devient donc :

h1{
    font: 1.7em/1em Arial, Helvetica, sans-serif;
}

Voila, vous avez fait le plus dur. Assurez-vous de toujours faire vos calculs après avoir fixé la taille par défaut (ici, 10 px) et de vérifier les arrondis à la calculatrice : ils peuvent différer d'un navigateur à l'autre.

Remarque : les éléments de formulaires

Pour que les éléments de formulaires s'affichent correctement, je vous recommande de leur donner une taille de 100%.

input, select, textarea{
    font-size: 100%;
}

Expérience utilisateur

Le code ci-dessus définit une taille de police de 10px dans les navigateurs où ce paramètre est à sa valeur habituelle. Si l'utilisateur augmente ou diminue la taille de police, l'ensemble du texte de la page s'adaptera automatiquement de manière équilibrée, améliorant ainsi son expérience.

Exemple de feuille de style

Dans mes projets, je sépare généralement les règles typographiques des autres, en les plaçant dans des fichiers différents. Cela m'aide à distinguer les règles utilisées pour la typographie de celles utilisées pour la mise en page. Voici un exemple de feuille de style typographique :

/* Spécifique à cette balise */
HTML{
    font-size: 100%;
}

body{
    /* La taille de base sera de 10px avec les valeurs par défaut de police du navigateur */
    font: 0.625em/1em Verdana, Geneva, Arial, Helvetica, sans-serif;
}

input, select, textarea{
    font-size: 100%;
}

h1{
    /* Par défaut, ce texte s'affichera à 20px */
    font: 2em/1em Verdana, Geneva, Arial, Helvetica, sans-serif;
}

h2{
    /* Par défaut, ce texte s'affichera à 15px */
    font: 1.5em/1em Arial, Helvetica, sans-serif;
}

h3{
    /* Par défaut, ce texte s'affichera à 12px */
    font: bold 1.2em/1em Verdana, Geneva, Arial, Helvetica, sans-serif;
}

Fiche technique

  • Article original : How to specify dynamic font sizes consistently with CSS
  • Auteur : Robert Nyman
  • Date de parution : février 2007
  • Traduction : Goulven Champenois
  • Date de traduction : septembre 2007
  • Thèmes : CSS, Accessibilité
  • Niveau : Intermédiaire


Pompage.net - CSS : on reprend tout à zéro !

Écrire des feuilles de style efficaces

Par Holly Bergevin et John Gallant

Les bénéfices de l'efficacité

Un des avantages des CSS les plus mis en avant est qu'elles réduisent le poids total d'une page, et donc le temps de téléchargement, lors des chargements successifs d'une page grâce à la mise en cache de la feuille de style. C'est bien sûr vrai, mais bien souvent une fraction non négligeable des économies réalisées au premier chargement est perdue à cause d'un code CSS beaucoup trop redondant.

Eh bien ce problème n'en est plus un, car vous allez maintenant apprendre quelques-uns des petits «secrets » d'un codage CSS efficace, vous permettant de dépouiller au maximum vos feuilles de style. Bien sûr, les économies que vous allez réaliser ne seront pas énormes, mais pour certains sites très compétitifs, il n'y a pas de petits profits.

Il y a plusieurs domaines où la chasse aux octets superflus peut s'exercer. Ils comprennent notamment les propriétés raccourcies, les déclarations multiples, les valeurs par défaut, l'héritage des règles et les espaces blancs.

Les propriétés raccourcies

Un certain nombre de propriétés raccourcies ont déjà été effleurées dans l'article Zeroing page margins, mais il y a encore beaucoup à dire sur le sujet.

Les propriétés raccourcies les plus communément utilisées sont :

  • font (qui contrôle font-size, font-weight, line-height, etc.)
  • background (qui contrôle les éléments d'arrière-plan, leur positionnement, leur répétition, etc.)
  • list-style (qui établit les propriétés des « puces» dans les listes d'items)
  • margin (qui définit la largeur des marges des côtés d'une boîte)
  • border (qui définit les propriétés des bordures d'une boîte. Il existe plusieurs propriétés raccourcies impliquant des bordures)
  • padding (qui définit la largeur de la «marge interne » d'une boîte)

les éléments de la liste ci-dessus renvoient aux spécifications CSS2 du W3C.

La propriété font est par exemple une propriété raccourcie qui permet d'établir d'un seul coup les propriétés font-style, font-variant, font-weight, font-size, line-height et font-family, même s'il n'est pas obligatoire de définir chacune d'entre elles. Quand une valeur est omise dans la formulation raccourcie, chaque propriété «manquante » est assignée à sa valeur initiale telle qu'elle a été définie pour la propriété font dans la spécification du W3C. Si plusieurs propriétés doivent être utilisées pour contrôler votre texte, l'utilisation de font permettra de supprimer un nombre substantiel d'octets dans une feuille de style.

Les propriétés background et list-style fonctionnent de manière similaire. Quant aux propriétés raccourcies restantes, elles concernent les quatre côtés d'une boîte CSS et sont un peu différentes.

Les propriétés raccourcies des côtés de boîte

Les quatre côtés de tous les éléments de niveau bloc (div, tableaux, listes, paragraphes, etc.) ont chacun une marge, une bordure et un remplissage (padding - NDT) dont la largeur peut être établie de manière variable pour chacun des côtés. Dans le cas des bordures, border-style et border-color peuvent aussi être définies séparément pour chaque côté. Si toutes ces propriétés doivent être écrites de façon explicite, l'ensemble des règles peut devenir relativement long. Utiliser des raccourcis permet de réduire considérablement le poids.

«L'horloge »

Quand il est nécessaire d'utiliser une des propriétés «côté de la boîte » et que tous les côtés sont identiques, vous pouvez simplement utiliser les propriétés raccourcies de la manière suivante :

margin: 10px;
border-width: 1px;
padding: 5px;

Remarque : border-style doit aussi être définie si l'on souhaite faire apparaître les bordures de la boîte. L'utilisation de border-width seule n'entraînera aucun affichage. Ceci peut être réalisé à l'aide de la propriété border-style, ou en définissant un style avec la propriété border.

Si toutefois certains côtés de la boîte doivent avoir des valeurs différentes, on peut utiliser une caractéristique des CSS que nous appelons «l'horloge ». Imaginez votre boîte comme une horloge vue de face. Quand les aiguilles sont pointées vers le haut, elles indiquent le sommet de la boîte, qui sera la première valeur de la propriété raccourcie. Vient ensuite la position des 3 heures qui est la valeur du côté droit, puis celle des 6 heures pour la valeur du bas de la boîte, et finalement la position 9 heures qui indique la valeur du côté gauche.

Ainsi par exemple, si nous voulons sur notre page une boîte avec une marge haute de 10px, une marge droite de 5px, une marge basse de 3px, et une marge nulle sur la gauche, voici comment la propriété raccourcie margin devra être écrite :

margin: 10px 5px 3px 0;

Dans la déclaration de la propriété, les valeurs doivent être séparées par un espace, et un espace seulement. De plus, les unités de mesure doivent être spécifiées pour chacune des valeurs, à moins qu'elles ne soient nulles. Remarquez que la taille nulle de la propriété margin est définie par un 0, car il est inutile de préciser l'unité utilisée quand une valeur est nulle. La valeur 0 de toute unité (px, em, %, etc.) est égale à la valeur 0 de n'importe quelle autre unité.

Horloges modifiées

Les différentes propriétés raccourcies de type «côté de la boîte » permettent encore plus de compression quand certains des côtés sont identiques. Comme mentionné précédemment, quand tous les côtés de la boîte sont similaires, une valeur unique s'appliquera à l'ensemble. Cependant, si le haut et le bas de la boîte doivent être définis d'une certaine façon, tandis que la gauche et la droite doivent être différents, le code de la propriété margin peut être écrit de la manière suivante :

margin: 10px 5px;

Ce code définit la marge supérieure et la marge inférieure à 10px, et les marges de côté à 5px. Un dernier truc est possible si le haut et le bas de la boîte sont différents alors que les côtés restent identiques. Avec une marge supérieure de 10px, une marge droite et gauche de 5px, et une marge inférieure de 20px, on peut écrire :

margin: 10px 5px 20px;

Tout dépend du nombre de valeurs à appliquer à la propriété raccourcie et de leur ordre. Rappelez-vous, une valeur = tous les côtés ; deux valeurs = le haut et le bas, puis les côtés ; trois valeurs = le haut, les côtés, le bas ; quatre valeurs = suivez le cadran de votre montre. Voilà, ça n'était pas si difficile !

Des bordures différentes

Cette même méthode peut être utilisée avec la propriété raccourcie border comme avec la propriété padding. border-color, border-style et padding fonctionnent de la même manière que la propriété margin. Il y a cependant une différence pour la propriété border puisque celle-ci établit une border-width, une border-style et une border-color pour les quatre côtés d'une boîte.

Ceci fonctionne très bien si les quatre côtés sont identiques. Mais que se passe-t-il s'ils doivent être différents ? Devrons-nous utiliser les bonnes vieilles border-top, border-right,etc. ? Eh bien on pourrait. Heureusement, il existe une façon un petit peu plus efficace de le faire.

Admettons que les bordures de notre boîte doivent toutes avoir le même style et la même couleur, mais des largeurs différentes. Le moyen le plus efficace de le faire est d'utiliser la propriété raccourcie basique border pour définir, comme d'habitude, la border-width, la border-style et la border-color, puis d'utiliser séparément la propriété border-width pour réécrire les différentes largeurs des bordures de la manière suivante :

border: 10px solid red;
border-width: 10px 5px 3px 0;

Si toutes les propriétés border sont différentes pour chacun des côtés, cette méthode ne sera pas d'un grand secours, mais ce n'est pas la situation la plus typique. Si ce sont les propriétés border-style ou border-color qui doivent être variables, alors cette méthode peut être adaptée pour fonctionner avec ces propriétés comme avec border-width.

Jetons maintenant un coup d'oeil à une situation où l'écriture d'une CSS efficace peut vraiment faire la différence.

Les déclarations multiples

Disons que nous avons six div (six calques dans Dreamweaver) positionnés de manière absolue qui sont tous identiques, si ce n'est qu'ils sont placés l'un à côté de l'autre au sommet de la page. Parce que leur positionnement est différent, ils doivent avoir un attribut class ou un ID individuel, et pour le reste des propriétés identiques.

Un éditeur graphique écrira certainement une règle CSS séparée pour chaque ID comprenant toutes les règles de police, de texte, de positionnement, etc... Mais n'est-il pas idiot de répéter les mêmes règles pour toutes ces div ? Ça l'est. Aussi, voici comment les condenser au maximum :

#premier {left: 0;}

#deuxieme {left: 100px;}

#troisieme {left: 200px;}

#quatrieme {left: 300px;}

#cinquieme {left: 400px;}

#sixieme {left: 500px;}

#premier, #deuxieme, #troisieme, #quatrieme, #cinquieme, #sixieme {
    position: absolute;
    top: 0;
    width: 75 px;
    font-size: .9em;
    font-weight: bold;
    text-align: center;
    line-height: 1.4em;
    background-color: silver;
    color: navy;
    padding: 5px;
    border: 1px solid navy;
}

En listant tous les ID des div identiques, séparés par une virgule et un espace, le bloc de règles s'applique à tous les div en même temps. Il est évident que si toutes ces propriétés avaient dû être répétées pour chaque ID, la feuille de style en aurait été gonflée d'autant. Voilà peut-être la méthode la plus efficace pour réduire la taille d'une feuille de style.

Remarque : Assurez-vous que le sélecteur du dernier ID ne comporte pas de virgule et apparaisse exactement comme dans l'exemple ci-dessus. Bien que certains navigateurs pourraient continuer à afficher les div, d'autres considéreront qu'il s'agit d'une erreur et n'afficheront aucun div.

Les valeurs par défaut

De nombreuses propriétés CSS ont une valeur initiale qui sera utilisée pour un élément si aucune déclaration ne vient réécrire cette valeur. Par exemple, chaque propriété de padding, c'est-à-dire padding-top, padding-right, padding-bottom, et padding-left possède une valeur initiale de 0. Si aucun remplissage n'est souhaité pour un élément donné, la propriété padding peut donc être omise.

Remarque : Les propriétés raccourcies comme celles dont nous venons de parler n'ont pas en elles-mêmes de valeur par défaut, et leurs différentes valeurs initiales sont généralement issues de la propriété individuelle que la version raccourcie représente. Alors qu'un certain nombre de valeur par défauts, listées dans l'index des propriétés de la spécification CSS2, sont égales à none ou 0, certains navigateurs établissent d'eux même des valeurs par défaut différentes pour certaines propriétés en fonction des éléments.

Exemple : le navigateur Opéra établit le positionnement de l'élément body à 8px. Les éléments h1 à h6 ainsi que les paragraphes ont généralement une valeur non nulle par défaut. L'utilisation d'une marge ou d'un espacement nul pour les listes ou les items d'une liste varie selon les navigateurs.

L'héritage des règles

Une autre façon d'éviter le code redondant est de prendre conscience du fait que les propriétés peuvent se transmettre d'un élément parent vers un élément enfant. Ces propriétés héritables sont peu nombreuses et la plupart servent très rarement, comme voice-family. La liste des propriétés couramment utilisées qui peuvent se transmettre est plutôt courte, alors la voici par ordre alphabétique :

  • color
  • font (et ses propriétés reliées)
  • letter-spacing
  • line-height
  • list-style (et ses propriétés reliées)
  • text-align
  • text-transform
  • white-space
  • word-spacing

Dans certains vieux navigateurs, les caractéristiques de l'héritage peuvent être défaillantes, mais les navigateurs modernes ne posent généralement aucune difficulté. En connaissant les propriétés héritables, on peut éviter d'écrire un code excessif. Alors n'hésitez pas à regarder encore le listing complet de l'index des propriétés CSS2.

Les espaces blancs

Il ne s'agit pas ici de la propriété white-space qui possède certaines valeurs spécifiques, mais plutôt de l'espace vide qui fait partie de la feuille de style elle-même. Cet espace se manifeste sous la forme des retours-chariot créant une nouvelle ligne et des espaces insérés à l'intérieur d'une ligne pour en faciliter la lecture. Bien que la suppression de tels espaces permette d'économiser quelques octets, les gains de poids restent en général très réduits.

Si les espaces vides sont supprimés, la feuille de style deviendra très difficile à lire, rendant les modifications ultérieures fastidieuses. Toutefois, si le travail impose que le moindre excès de poids soit supprimé, vous pouvez créer un fichier CSS «maître » facilement lisible. Puis, faites-en une copie et enlevez tous les espaces blancs du fichier qui sera utilisé en ligne. Si des changements doivent intervenir par la suite, ils seront effectués sur le fichier maître. On en refera une nouvelle copie qui sera à nouveau nettoyée de tous ses espaces blancs, et utilisée pour la version en ligne.

Attention ! Certains espaces du code CSS sont obligatoires et leur suppression altérera le fonctionnement des règles en conduisant à des effets plus qu'indésirables. Les spécifications du W3C utilisent la formulation "space separated" quand les espaces sont obligatoires. On les trouvera typiquement entre les valeurs des propriétés raccourcies. Le combinateur descendant, auquel on se réfère parfois comme le sélecteur descendant, est un caractère d'espacement, ce qui fait que la suppression de tous les espaces dans les sélecteurs n'est pas non plus une bonne idée. Alors peut-être vaut-il mieux laisser la suppression des espaces blancs aux véritables fanatiques ?

Conclusion

Vous venez d'apprendre un certain nombre de méthodes pour rendre vos feuilles de styles plus efficaces. Les avantages de l'utilisation régulière de ces techniques sont non seulement une économie d'octets quand la feuille de style sera téléchargée, mais aussi un code plus clair qui sera généralement plus facile à modifier. Même si vous construisez votre feuille de style avec un éditeur graphique, rien ne vous empêche d'éditer le résultat final pour le rendre plus efficace grâce aux méthodes esquissées dans cet article.

Fiche technique

  • Article original : How To write Efficient CSS
  • Auteur : Holly Bergevin et John Gallant
  • Date de parution : 2003
  • Traduction : Philippe Janvier
  • Date de traduction : novembre 2004
  • Thème : CSS
  • Niveau : Intermédiaire


Pompage.net - CSS : on reprend tout à zéro !

Faites bonne impression avec les CSS

Par Eric A. Meyer

Vous les avez forcément déjà croisés : des liens qui disent « Cliquez ici pour une version imprimable », ou une phrase du même genre. Chaque fois que vous suivez un de ces liens, vous chargez un document séparé qui présente exactement la même information avec une autre mise en page, et probablement un balisage différent.

Cela veut dire que quelqu'un (ou un script) a dû prendre le document original et le convertir en une version dépouillée plus adaptée à une sortie papier. Ce quelqu'un, c'était peut-être vous.

Les feuilles de styles imprimante à la rescousse

Une des merveilles du CSS, c'est qu'il permet, pour un même document, de créer différents styles propres à un médium spécifique (styles media-specific). Nous sommes déjà habitués à créer des styles pour le rendu écran, mais penser aux autres médias n'est pas encore devenu un réflexe. Et, comme l'attestent tous les liens de « versions imprimables », notre réflexion sur l'impression s'est limitée à recréer un document autrement.

Mais pourquoi se fatiguer, quand la capacité d'offrir à vos lecteurs un meilleur contenu imprimé ne demande qu'un document bien structuré et une feuille de styles media-specific?

En effet, vous pouvez prendre n'importe quel document (X)HTML et simplement lui adjoindre une feuille de style pour l'impression, sans avoir à toucher au balisage. Ainsi, les problèmes de différence entre versions web et papier appartiennent désormais au passé. Cerise sur le gâteau, la réalisation est simple. (Pour plus d'informations sur les principes de base de la création de feuilles de styles media-specific en général et les styles « papier » en particulier, voyez « Print Different » sur meyerweb.com.)

Voyons maintenant comment le site A List Apart s'est trouvé pourvu de feuilles de styles papier qui, tout en esquivant un bug de navigateur, ont rendu la sortie imprimée bien meilleure.

Réparer un float flappi

Comme vous pouvez le voir en allant voir la liste des bugs connus de A List Apart (NdT : ce lien est désormais malheureusement mort), ou en visitant l'article n°104040 de Bugzilla, les navigateurs basés sur Gecko, comme Netscape 6.x ou Mozilla, ont du mal à imprimer de longs éléments flottants. Si un élément flottant dépasse le bas d'une page imprimée, le reste du contenu flottant disparaît, n'étant pas imprimé sur la page suivante.

Cela veut dire que si vous avez un site utilisant un style similaire à celui de A List Apart, avec tout le contenu d'un article dans un même bloc flottant, les lecteurs ne pourront récupérer que la première page de l'article.

En fait, l'astuce est de supprimer le flottement du contenu quand la page est imprimée. En termes simples, tout ce que vous avez à faire c'est d'assigner float: none à tout élément flottant. Cela ramène l'élément flottant dans le « flot » normal du document, qui est alors imprimé comme vous le vouliez, une page à la fois jusqu'à la fin de l'article.

J'ai donc fait cette recommandation à Jeffrey Zeldman pour ALA, ce qui a résolu le problème d'impression. A l'heure où j'écris ceci, les navigateurs basés sur Gecko ont toujours ce bug, mais au moins il peut être facilement contourné.

Le point de départ

Voici la feuille de style papier qu'utilisait A List Apart une fois le bug de flottement réglé:

#menu {
    display: none;
    }

#wrapper, #content {
    width: auto;
border: 0;
margin: 0 5%;
padding: 0;
float: none !important;
    }

C'est un bon début. Cette feuille de style escamote complètement le menu de droite du document pour qu'il ne soit pas imprimé, et redéfinit les marges et le remplissage (padding) du contenu de l'article pour que le texte remplisse la page imprimable d'un côté à l'autre.

Le problème, pour moi, c'était que trop des styles destinés à l'écran se retrouvaient dans l'impression. Si nous regardons le head d'un article récent de ALA, nous trouvons (entre autres) les lignes suivantes:

<style type="text/css" media="all">
    @import "nucss2.css";
</style>

<link rel="stylesheet"
    type="text/css"
    media="print" href="print.css" />

Nous avons une feuille de style, print.css, qui a été restreinte au médium imprimante grâce à l'attribut media. La feuille de style nucss2.css, qui est importée afin d'être invisible à Navigator 4.x, est utilisée dans tous les médias que supporte le navigateur : écran, imprimante, projecteur, lecteur vocal, etc. Si l'on n'est pas prudent, on peut se retrouver avec des couleurs d'arrière-plan et des tailles de polices en pixels dans notre rendu imprimé.

Occupons-nous donc de ces problèmes de mise en page, et de quelques autres.

Fonds blanchis

Beaucoup de couleurs d'arrière-plan sont appliquées aux objets de la barre de navigation de droite. Puisqu'elle disparaît dans la version papier, pas besoin de s'embêter à changer quoi que ce soit dans cette barre. Ce qui nous évite tout de suite de nombreuses migraines potentielles.

Puisque les imprimantes n'impriment pas le blanc, il faut passer l'arrière-plan de la page en blanc. Il faut aussi enlever toute image d'arrière-plan qui se serait glissée dans la version papier.

Si nous utilisons simplement la propriété background, nous pouvons accomplir ces deux tâches avec une seule valeur. Pour nous laisser un peu de flexibilité, nous allons régler l'arrière-plan de body en blanc, et les arrière-plans des éléments de contenu (content) et de couverture (wrapper) en transparent (laissant ainsi apparaître le blanc à travers) :

body {
    background: white;
    }

#menu {
    display: none;
    }

#wrapper, #content {
    width: auto;
    margin: 0 5%;
    padding: 0;
    border: 0;
    float: none !important;
    color: black;
    background: transparent;
    }

Régler la couleur de premier plan n'est pas absolument nécessaire, mais c'est toujours une bonne idée. Maintenant nous avons deux éléments non flottants (#wrapper, #content) sans arrière-plan visible, et une page avec un arrière-plan blanc.

Au cas où vous vous inquiéteriez que Navigator 4.x fasse des choses terribles à la valeur transparent, réjouissez-vous N: N4 ne remarque que les feuilles de style qui ont une valeur de media pour screen. Exactement comme avec @import, les styles de notre feuille de style papier sont dissimulés à tout jamais aux yeux chassieux de Navigator 4. Pas de soucis, donc.

Retailler la police pour l'impression

La feuille de style tous media taille le texte imprimé à 11px, un choix discutable. La famille de polices (Georgia d'abord, des polices serif ensuite) est bonne pour l'impression, où les polices serif sont généralement préférées. Seule la taille a besoin d'un changement. D'où :

body {
    background: white;
    font-size: 12pt;
    }

« Une seconde! », vous exclamez-vous sans doute. « Hérétique! Tout le monde sait que les points sont mauvais! C'est Todd Fahrner qui l'a dit! » Eh bien oui, il l'a dit, et il avait entièrement raison: pour le media écran, les points sont un choix épouvantable. Pour l'impression en revanche, les points sont depuis longtemps l'unité de référence. Et puisque nous sommes en train de créer un style pour une impression papier, une taille de police de body à 12 points est en fait un excellent choix.

Vous pouvez bien sûr choisir n'importe quelle taille, mais 12 points est une taille très courante. Et puisque les styles tous media de Zeldman taillent les éléments du contenu des articles relativement à body, nous sommes parés.

En marge

Les styles existant pour les divs wrapper et content ont leur marges de droite et de gauche fixées à 5%. Ce qui veut dire qu'il y aura un espace vide de chaque côté de l'article, et que chaque zone vide fera 10% de la zone imprimable de la page. En effet, div content se trouve à l'intérieur de wrapper, et ils ont tous les deux 5% de marge de chaque côté. Additionnez le tout et vous obtenez 10%.

Les styles tous media originaux fixent un remplissage à droite (padding) de 15% pour le div content. Les marges nous donnant déjà 10%, nous avons donc juste besoin de 5% supplémentaires, ce qui est très facile à obtenir:

div#content {
    margin-left: 10%;
    }

Une autre possibilité aurait été de laisser la marge tranquille et de donner au remplissage à gauche une valeur de 5%. Puisque le div content n'a pas d'arrière-plan visible, les deux approches devraient avoir le même effet.

Malheureusement, certains navigateurs ont du mal à contrôler correctement le remplissage; il vaut donc mieux pour le moment contourner le problème en utilisant les marges autant que possible.

Liens imprimés

Une question délicate était celle des hyperliens. De toute évidence ils ne sont pas aussi utiles sur papier que sur écran, mais il est souvent important d'indiquer qu'il y avait des liens dans l'original. Voici ce que j'ai donc conçu:

a:link, a:visited {
    color: #520;
    background: transparent;
    font-weight: bold;
    text-decoration: underline;
    }

Ceci donne aux liens une couleur suffisamment sombre pour être proche du noir dans une impression en dégradés de gris, mais avec quand même une couleur rouge foncé qui apparaîtra sur une impression couleur. La mise en gras et le soulignement garantissent le contraste des textes de liens.

Dans un navigateur totalement conforme avec le CSS2, nous pouvons insérer entre parenthèses les URL des liens après chacun d'entre eux, les rendant ainsi utiles à quiconque ayant sous la main une copie du document et un navigateur. Voici la règle, qui restreint cet effet au div content et évite donc de coller une URL sur le titre général:

#content a:link:after, #content a:visited:after {
  content: " (" attr(href) ") ";
  font-size: 90%;
  }

Essayez cette règle dans un navigateur basé sur Gecko, comme Mozilla ou Netscape 6.x. Après chaque lien de la version papier, vous devriez voir l'URL du lien entre parenthèses.

Dans tout autre navigateur qui ne comprendrait pas cette règle, il ne devrait pas y avoir de conséquences désastreuses : les liens seront toujours en rouge foncé, soulignés et en gras. Aucune URL n'apparaîtra après le texte du lien, c'est tout.

Notez que les espaces avant et après la parenthèse font bien partie de la règle ci-dessus: les espaces doivent y apparaître pour être insérés dans le document.

Il y a tout de même un problème d'esthétique avec cette nouvelle règle, précisément parce qu'elle entraîne l'insertion verbatim de la valeur de l'attribut href de chaque lien.

D'autre part, si nous jetons un œil au code des pages de ALA, nous remarquons rapidement qu'il y a un grand nombre d'URL relatives comme /issues/144. Elles sont insérées dans le document telles quelles, ce qui les rend moins utiles que si elles étaient affichées comme une URL absolue.

Or, il se trouve que les sélecteurs du CSS3 nous offrent une solution. N'importe quel sélecteur d'attribut qui utilise l'opérateur ^= sélectionne des éléments basés sur le début de la valeur de l'attribut. Nous pouvons donc sélectionner n'importe quel href qui commence par une barre oblique et insérer suffisamment de texte pour remplir la valeur.

#content a[href^="/"]:after {
  content: " (http://www.alistapart.com" attr(href) ") ";
  }

Cette règle transforme une valeur comme /issue/144/ en http://www.alistapart.com/issues/144/. Elle ne peut rien pour les URL relatives qui ne commencent pas par des barres obliques, mais heureusement ALA n'en utilise pas.

Étendre le bloc titre

En effectuant une dernière relecture des styles papier, j'ai réalisé que le bloc titre du site m'embêtait. Pas tant par sa présence que par son « soulignement », qui faisait partie de l'image. Le souligné, bien sûr, s'arrêtait au bord de l'image. Il m'est apparu qu'il serait possible de faire un petit tour de passe-passe et d'étendre cette ligne à la largeur du texte de l'article.

La première étape était de donner au div content une bordure haute qui soit, comme le soulignement de l'image, une ligne continue rouge foncé d'1 pixel. Comme j'allais créer une bordure haute pour le contenu, il semblait aussi une bonne idée d'insérer du remplissage entre la bordure et le contenu.

div#content {
    margin-left: 10%;
    padding-top: 1em;
    border-top: 1px solid #930;
    }

Tout seul, ce code dessinerait une ligne juste en dessous de l'image du titre. Comme il se trouve que ladite image est enveloppée dans un élément div qui ne sert qu'à elle, la marge basse de ce div est donc utilisée pour tirer à lui le reste du contenu.

div#mast {
    margin-bottom: -8px;
    }

div#mast img {
    vertical-align: bottom;
    }

Ces règles simples font que la bordure haute du div content s'aligne avec le soulignement de l'image du titre. La bordure se trouve en fait posée par-dessus l'image, mais comme les couleurs s'accordent il est difficile (sinon impossible) de se rendre compte de ce qui ce passe. Même si un navigateur décidait de mettre l'image par-dessus la bordure haute du contenu, l'image et la bordure seraient tout de même alignées et créeraient l'illusion.

La deuxième règle, celle avec vertical-align, contourne un comportement intéressant de Mozilla qui n'est constaté que lorsqu'un document est rendu en mode « standards », comme le sont tous les articles de ALA. [Voir Better Living Through XHTML]

En ce qui concerne la couleur de fond de l'image du titre, il n'y a vraiment aucun moyen de l'enlever à part rendre transparents les pixels qui la composent. On pourrait assigner une couleur de fond similaire au div du titre, mais cela serait pousser le bouchon un peu loin pour un arrière-plan si léger.

Quoi d'autre?

Voilà tout ce que nous avons fait pour ce re-design, mais les possibilités sont loin d'être épuisées.

On pourrait par exemple bricoler les couleurs pour qu'elles passent mieux à l'impression, ou modifier les marges pour qu'elles soient réglées en points (ou en picas, ou même en cm.) au lieu de pourcentages. Dans le monde de l'impression papier, vous avez presque autant de liberté de design que sur écran.

Un domaine que nous n'avons pas creusé aussi en profondeur que nous l'aurions pu est la taille de polices. Un certain nombre de classes, comme superfine, ont été laissées à la charge des styles tous media, et donc traitées en pixels. Les retailler pour le papier est aussi simple que ce que nous avons fait pour l'élément body : il suffit d'écrire une règle qui traite les éléments en question, et assigne une nouvelle valeur à font-size.

Pour prendre un exemple, nous aurions pu écrire .superfine {font-size: 9pt:}... ou n'importe quelle valeur appropriée. D'autres éléments, comme les pieds de page et pre, auraient pu bénéficier d'un travail similaire, et il se pourrait que ce soit le cas dans de futures versions des feuilles de style papier de ALA.

Le résultat final

Voici la feuille de style papier que nous avons obtenue après changements.

body {
  background: white;
  font-size: 12pt;
  }
#menu {
  display: none;
  }
#wrapper, #content {
  width: auto;
  margin: 0 5%;
  padding: 0;
  border: 0;
  float: none !important;
  color: black;
  background: transparent none;
  }
div#content {
  margin-left: 10%;
  padding-top: 1em;
  border-top: 1px solid #930;
  }
div#mast {
  margin-bottom: -8px;
  }
div#mast img {
  vertical-align: bottom;
  }
a:link, a:visited {
  color: #520;
  background: transparent;
  font-weight: bold;
  text-decoration: underline;
  }
#content a:link:after, #content a:visited:after {
  content: " (" attr(href) ") ";
  font-size: 90%;
  }
#content a[href^="/"]:after {
  content: " (http://www.alistapart.com" attr(href) ") ";
  }

Aussi minimale et (par certains aspects) rudimentaire que puisse être cette feuille de style, son action devrait sauter aux yeux de n'importe quelle personne comparant une version imprimée à l'article en ligne. Des modifications similaires et tout aussi spectaculaires sont possibles pour presque n'importe quel design, du simple au sublime, et ce genre de styles media-specific libère les auteurs de l'obligation de créer une copie « facile à imprimer » d'un document.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : CSS Design: Going to Print
  • Auteur : Eric A. Meyer
  • Date de parution : 10 mai 2002
  • Traduction : Samuel Latchman
  • Date de traduction : novembre 2002
  • Niveau : Intermédiaire


Pompage.net - CSS : on reprend tout à zéro !

Feuilles de Styles en Cascades, Promesse contre Réalité, et un regard vers le Futur

Par Mark Newhouse

Les Feuilles de Style en Cascades (CSS) sont une technologie prometteuse, mais leur potentiel, souvent réduit à un phénomène de mode, laisse quelques concepteurs aveugles aux imperfections de la réalité. Cet article évoque les différences qui subsistent entre promesse et réalité, et vous fournit une occasion de vous former maintenant en préparation du futur.

Se jeter à l'eau

Vous en avez entendu parler dans les forums de discussion sur le WebDesign et sur les listes de diffusion. Vous avez lu des articles à propos de l'abandon des tableaux en faveur des gabarits basés sur les standards CSS sur des sites comme A List Apart et Web Reference. Peut-être avez-vous visité quelques sites qui offrent des gabarits sans tableaux prêts à l'emploi. Aussi vous creusez la question et commencez à découvrir de petites divergences d'exécution suivant les navigateurs. Vous réalisez alors que certaines de ces divergences ne sont pas si infimes.

Bidouillage du Modèle de Boîte ? "Qu'est-ce qu'un modèle de boîte ?" vous demandez-vous en râlant. " Que diable peut bien signifier ce voice family:"\"}\""; et comment l'utilise-t-on pour créer une feuille de style ?".

Vous en êtes venu à réaliser que les CSS ne sont pas la panacée qu'elles devraient être. Un fossé énorme sépare promesse et réalité.

Combler le fossé

Mais le canyon est-il vraiment aussi large ? Vous souvenez-vous de la manière dont vous avez lutté pour maîtriser les tableaux alors que désormais vous pouvez les écrire les yeux fermés. Peut-être après tout y a-t-il quelque chose dans ce que l'on nomme CSS.

Si vous en êtes arrivés à ce stade de compréhension de l'utilisation des feuilles de style, vous n'êtes pas seul. Le confort et la familiarité des gabarits basés sur les tableaux rendent difficiles leur abandon. Et comme vous étudiez quelques-unes des promesses des CSS dans une perspective de la réalité actuelle comme dans une vision de plus long terme, j'espère avoir ici une occasion d'encourager ceux d'entre vous qui, assis sur la barrière, hésitent encore à descendre du côté des CSS et du (X)HTML bien structuré.

Je pense que vous trouverez l'herbe vraiment plus verte par ici et si vous n'aimez pas l'herbe verte - appliquez simplement un nouveau style.

Alors jetons donc un œil sur quelques promesses des CSS et voyons si nous pouvons percevoir le futur des feuilles de style dans notre boule de cristal.

Promesses, promesses

Promesse : Les feuilles de style élimineront les besoins de gabarits complexes fondés sur les tableaux.

Réalité : Même si les navigateurs supportent de mieux en mieux le standard CSS, il y a encore beaucoup de navigateurs qui ne gèrent pas suffisamment bien le positionnement pour inciter tout le monde à en changer. Et même parmi les navigateurs répandus qui permettent vraiment le positionnement, il existe suffisamment d'interprétations différentes et de mauvaises interprétations du modèle de boîte, et d'autres choses encore, pour que dans beaucoup de cas nous ne soyons pas prêts à échanger notre façon de travailler pour une autre.

Au moins les nouvelles habitudes fonctionnent. Mais tant que nos clients voudront la même apparence dans Netscape 4.x, la majorité de vos conceptions s'en tiendront à un gabarit à base de tableaux (voir le New York Public Library Online Style Guide).

Futur : Une fois que les navigateurs supporteront pleinement CSS1 et CSS2, et que les utilisateurs auront tous effectué leurs mises à jour, nous pourrons envoyer paître les méthodes de travail que nous utilisons actuellement (et serons prêts à en trouver de nouvelles pour les mauvaises interprétations de CSS3 et au delà). Si nous codons maintenant avec cet avenir en tête, il sera simple de laisser tomber les .css basiques au profit des .css avancées et nous serons aussi capables d'envoyer paître les TABLEs en faveur des DIVs.

Promesse : Les feuilles de style permettent une vraie séparation entre style et contenu.

Réalité : On préférera lire "séparation entre style et structure". Ce que les CSS permettent. Mais avec la compréhension que cette séparation est liée à la première promesse mentionnée ci-dessus. De sorte que tant que nous tiendrons à ce que les choses s'affichent de la même façon dans Netscape 4.x, nous devrons renoncer à cette séparation pendant un moment.

Le simple fait d'utiliser les CSS ne veut pas dire que vous publiez forcément de façon correctement structurée. Mais comme le proclame le validateur CSS du W3C : "Pour fonctionner comme prévu, votre feuille de style CSS a besoin d'un document correct pour faire l'analyse de son arborescence. Cela veut dire que vous devez utiliser du (X)HTML valide."

Futur : L'avenir s'y prête bien, en supposant que tout le monde saisisse les concepts de style et de structure. C'est une partie importante du mouvement des standards, et ce n'est qu'une question de temps, avant que tous, et tous les éditeurs WYSIWIG, ne produisent du (X)HTML pour structurer le document et des CSS valides pour mettre en forme.

Promesse : Les feuilles de style vous donnent un contrôle absolu sur la mise en page de votre document.

Réalité : L'utilisateur final aura toujours (et devrait toujours) avoir le dernier mot pour décider comment votre site Web s'affichera dans son navigateur. Plus tôt les concepteurs de sites accepteront cet état de fait et commenceront à concevoir pour le Web (et non pour l'impression, la télévision ou tout autre média), plus vite nous pourrons entrer dans cette nouvelle ère excitante de la conception Web. Pour ceux qui ne peuvent se faire à cette idée, il restera toujours le Flash et le PDF.

Futur : Le contrôle absolu de la mise en page d'un document n'a jamais été une vraie promesse des CSS. Il est vrai que les CSS fournissent des mécanismes pour créer des affichages précis au pixel près. Et cet affichage apparaîtra de la même manière dans tous les navigateurs appropriés - à moins que l'utilisateur final ne l'outrepasse. Puisque la plupart des utilisateurs ne savent pas comment - ni même si c'est possible - outrepasser la feuille de style de l'auteur, ils verront simplement la page comme l'auteur l'a conçue.

Promesse : L'utilisation des feuilles de style rend votre site plus accessible.

Réalité : Utilisées à bon escient, tout au long des procédures décrites dans les Web Content Accessibility Guidelines, les feuilles de style iront très loin dans l'assistance à la création de sites Web accessibles. Même si cela fait beaucoup de conditions à remplir.

Là où les feuilles de style apportent vraiment une aide importante, c'est dans la mise en page qui ne nécessite plus d'avoir recours à de complexes tableaux imbriqués pour obtenir les effets désirés. Avant les feuilles de style, si vous vouliez une bordure autour de votre contenu vous deviez imbriquer un tableau dans un autre tableau. D'autres tableaux étaient souvent ajoutés plus tard pour les menus, les menus déroulants, les images découpées et ainsi de suite, provoquant un cauchemar au niveau de l'accessibilité. Les feuilles de style seules ne résolvent pas le problème, mais elles jouent un rôle vraiment important dans sa solution.

Futur : La bonne nouvelle est que les questions de l'accessibilité sont en train d'être abordées, non seulement dans l'arène du navigateur, mais aussi dans les outils qui vous aident à construire vos sites Web. La majorité des outils actuels a tendance à s'appuyer sur les balises FONT, les tableaux et les vieux bidouillages d'espacement gif. Mais maintenant que les navigateurs modernes supportent les CSS qui remplacent ces bidouillages, les versions les plus récentes de Dreamweaver et de Golive résolvent ces problèmes.

Promesse : Les feuilles de style amaigrissent le code et accélèrent le téléchargement de la page.

Réalité : Utilisées proprement, les feuilles de style font en fait plus qu'amaigrir le code et accélérer le téléchargement des pages. Créer un style lié qui fonctionne pour toutes les pages d'un site signifie qu'il est téléchargé une fois et mis en cache par le navigateur. Les pages qui ont besoin de styles spéciaux peuvent les incorporer dans leurs en-têtes, ou dans une feuille de style liée à part.

Mieux encore, l'utilisation des feuilles de style pour la disposition élimine le recours aux tableaux complexes imbriqués. Utiliser la pseudo-classe :hover sur les liens élimine le téléchargement additionnel de javascript et d'images. Utiliser une image en arrière-plan qui ne se répète pas signifie que vous n'avez pas besoin d'ajouter un espace blanc à droite et en dessous de cette image pour prévenir la répétition de celle-ci avec les moniteurs à haute résolution. Tout cela économise de la bande passante, particulièrement sur les sites très visités.

Futur : La bonne nouvelle est que tout ceci peut être réalisé aujourd'hui. Et quand les futurs navigateurs fonctionneront correctement, nous pourrons créer du code encore plus léger en éliminant les habitudes de conception actuelles.

Promesse : Utiliser les feuilles de style garantit désormais la compatibilité des sites Web avec les futurs navigateurs et les futures versions de (X)HTML.

Réalité : Tout cela se fonde sur le fait que les futurs navigateurs se conformeront à tous les standards qui seront mis en place à l'avenir. Ce qui représente une certaine inconnue à ce jour, puisque aucun des navigateurs du moment (NDT : à la date de rédaction de l'article) n'est encore capable de faire fonctionner correctement l'ensemble du CSS1.

Futur : La clé ici est que si vos pages valident maintenant, elles valideront dans le futur, et les navigateurs de la prochaine génération comprendront comment interpréter la déclaration DOCTYPE que vous avez utilisée pour vos documents.

Promesse : Les feuilles de style vous garantissent que les pages Web fonctionnent dans tous les navigateurs.

Réalité : Il n'y a pas beaucoup d'agents utilisateurs alternatifs (NDT : UAs) pour tester cette théorie. A part le navigateur typique du PC, la plupart des UAs actuels ne comprennent pas encore les feuilles de style. Les navigateurs pour les petits écrans des terminaux comme les PDA ignorent souvent les feuilles de style. A la place, ces UAs utilisent des bidouillages à base de tableaux et réorganisent le contenu de manière linéaire pour un affichage sur les plus petits écrans. Les téléphones cellulaires utilisent un langage de balisage complètement différent. La plupart des lecteurs d'écrans et des navigateurs oraux ne sont pas encore très rapides pour utiliser les styles qui font partie du CSS2. Les fabricants de navigateurs essayent encore de travailler au mieux pour générer des styles spécifiques d'impression tels que les sauts de page.

Futur : Cela ne peut que s'améliorer. La question posée ici est à quelle vitesse ces terminaux saisiront les spécifications en cours de façon à ce que nous puissions utiliser la pleine puissance des feuilles de style pour livrer notre contenu de la manière la plus appropriée à chaque type de terminal.

Promesse : Les feuilles de style rendent vos sites Web plus faciles à maintenir.

Réalité : Quand les feuilles de style sont utilisées à bon escient, à l'intérieur d'un document correctement structuré en (X)HTML, elles rendent un site plus facile à maintenir et à mettre à jour. Il est possible de modifier tout l'aspect et le ressenti d'une page ou d'un site entier en appliquant simplement une nouvelle feuille de style. Chris Casciano a créé ainsi 20 changements sur son site durant le mois de février de cette année. Et il y a sur le Web un bon nombre d'articles décrivant différentes méthodes pour basculer les styles sur une page ou sur un site, si vous voulez faire l'essai vous-même.

Bien que ce soit indirectement relié aux feuilles de styles, l'utilisation correcte du (X)HTML structuré - au lieu des tableaux et bidouillages GIF - rend les fichiers balisés plus faciles à lire, et de ce fait, plus facile à maintenir et à mettre à jour. On perd moins de temps à chercher dans le bazar des tableaux imbriqués pour trouver le contenu qui a besoin d'être modifié. Et quand le style est contenu dans un fichier différent, vous avez moins de chances de créer des problèmes avec l'affichage pendant la mise à jour du contenu.

Futur : Le futur est là. Un document bien structuré peut avoir de multiples feuilles de style qui s'y appliquent et qui font en sorte que tout fonctionnera comme annoncé. Changer est aussi simple que le chargement d'une nouvelle feuille de style sur le serveur.

Promesse : Les feuilles de style sont marrantes à construire. Elles fournissent des défis créatifs et de nouvelles opportunités d'apprentissage.

Réalité : Quand vous démarrez simplement avec les feuilles de style, elles peuvent ne pas vous paraître très drôles, mais elles lancent sûrement un défi à votre créativité, et leur apprentissage ne s'arrête jamais. Une fois que vous aurez en tête leurs modes de fonctionnement, vous trouverez ces défis plus amusants que frustrants.

Futur : Bien qu'aucun navigateur actuel ne supporte même pas la totalité du CSS1, sans parler du CSS2, et que le W3C façonne encore les spécifications du CSS3 et au-delà, je pense que le futur sera plein de défis, d'opportunités pour en apprendre plus, tout en procurant beaucoup d'amusements.

Attention les yeux !

Les CSS ressemblent à une jeune recrue prometteuse qui n'a pas encore réalisé tout son potentiel. Nous nous attendons désormais à ce que les navigateurs évoluent et se développent suffisamment pour profiter de tout ce qu'elles ont à offrir. Quelle que soit la façon dont vous l'envisagez, le futur s'annonce brillant !

Ressources

  • Digital Web Magazine's CSS resources
  • A List Apart articles about CSS
  • Web Reference article on CSS layouts
  • Box Model Hack
  • New York Public Library Online Style Guide
  • Web Content Accessibility Guidelines
  • Chris Casciano's CSS experiment
  • Alternative Style, from A List Apart

Fiche technique

  • Article original : Cascading Style Sheets, Promise vs. Reality, and a Look to the Future
  • Auteur : Mark Newhouse
  • Date de parution : 4 juin 2002
  • Traduction : Christophe Ducamp
  • Date de traduction : août 2003
  • Thème : CSS
  • Niveau : Tous niveaux


Pompage.net - CSS : on reprend tout à zéro !

Introduction au positionnement CSS

Par Noah Stokes

Si vous êtes un développeur ou un designer qui aime le code, les mises en page basées sur les CSS représentent le cœur même de votre travail. Histoire de rafraîchir la mémoire de certains, ou d’en aider d’autres à découvrir le sujet, jetons un coup d’œil à la propriété CSS position pour voir comment construire des thèmes CSS conformes aux standards et garantis sans tableaux.

Tout est dans la position

Le positionnement CSS est souvent mal compris. Parfois, enragé par un bug, nous appliquons différentes valeurs à la position d’un sélecteur quelconque, jusqu’à en trouver une qui fonctionne. C’est un processus pénible qui peut faire l’affaire un certain temps, mais il serait mieux de savoir pourquoi indiquer position: relative parvient à régler notre bug d’affichage. Mon but est que nous puissions aprendre les valeurs et les comportements de la propriété position, et surtout comprendre comment une valeur peut affecter notre mise en page. La spécification CSS nous offre cinq valeurs pour la propriété position : static, relative, absolute, fixed et inherit. Chaque valeur correspond à un objectif précis. C’est en comprenant cet objectif que l’on pourra maîtriser les mises en page en CSS.

Suivez le flot

Commençons par prendre un peu de recul pour reconnaître le terrain sur lequel nous travaillons. Tout comme dans la vraie vie, en CSS nous travaillons au sein de limites. En CSS, cette limite s’appelle le flux normal. On lit dans la spécification CSS 2.1 que :

Les boîtes dans un flux normal appartiennent à un contexte de mise en forme, bloc ou en-ligne, mais pas les deux en même temps. Les boîtes de bloc participent à un contexte de mise en forme bloc, les boîtes en-ligne à un contexte de mise en forme en-ligne.

(NDT : traduction française de la recommandation CSS 2 du W3C)

Il faut voir les « boîtes » décrites dans ce texte comme des cubes en bois, du même genre que ceux avec lesquels vous jouiez quand vous étiez gamin impétueux. Il vous faut maintenant voir le flux normal comme une loi semblable à la loi de la gravitation. Le flux normal du document, c’est la façon dont vos éléments s’empilent les uns sur les autres, de haut en bas, suivant l’ordre où ils apparaissent dans votre code. Souvenez‑vous quand vous construisiez des tours géantes avec vos cubes : le flux normal, c’est le même principe que ces cubes de bois liés entre eux par la loi de la gravitation. Dans votre jeu d’enfant, vous placiez les cubes les uns sur les autres ; dans votre balisage, vous obtenez un élément après l’autre. Une chose que vous ne pouviez pas faire quand vous étiez enfant, en revanche, était de donner à ces cubes des propriétés qui défieraient la loi de la gravitation. Tout d’un coup, les CSS paraissent nettement plus sympa que vos cubes.

Static et relative : rien de nouveau jusqu’ici

Les valeurs static et relative attribuées à position se comportent comme vos cubes en bois — ils se superposent les uns les autres. Notez que static constitue la valeur par défaut de tout élément, faute d’y appliquer une autre. Si vous mettez trois éléments positionnés en static dans votre code, ils vont se placer les uns sur les autres, sans surprise. Voyons cet exemple avec trois éléments, chacun recevant la valeur static pour la propriété position :

#box_1 {
  position: static;
  width: 200px;
  height: 200px;
  background: #ee3e64;
}

#box_2 {
  position: static;
  width: 200px;
  height: 200px;
  background: #44accf;
}

#box_3 {
  position: static;
  width: 200px;
  height: 200px;
  background: #b7d84b;
}

Dans l’exemple A, vous pouvez voir trois éléments superposés comme une simple tour. Merveilleux, n’est‑ce pas ? Vous venez de passer votre premier niveau de positionnement CSS. Félicitations !

Vous pouvez utiliser la valeur static pour des mises en page simples, à colonne unique, où chaque élément vient se poser sur le suivant. Si vous voulez commencer à déplacer ces éléments à l’aide de propriétés de décalage comme top, right, bottom et left, vous êtes coincé. Ces valeurs ne sont pas disponibles pour un élément static. En fait, un élément statique ne peut même pas créer un nouveau système de coordonnées pour des éléments descendants. Hein ? Quoi ? C’est quoi, cette histoire de « système de coordonnées » ? Ne bougez pas, j’ai compris le message. Je vais vous expliquer à l’aide de la valeur relative.

Les éléments qui reçoivent un positionnement relatif se comportent de la même façon que ceux qui sont statiques : ils s’entendent bien avec leurs voisins, s’empilent gentiment et ne mettent pas le bazar. À peine croyable, non ? Souvenez‑vous de notre exemple précédent. Cette fois, nous avons appliqué la valeur relative :

#box_1 {
  position: relative;
  width: 200px;
  height: 200px;
  background: #ee3e64;
}

#box_2 {
  position: relative;
  width: 200px;
  height: 200px;
  background: #44accf;
}

#box_3 {
  position: relative;
  width: 200px;
  height: 200px;
  background: #b7d84b;
}

L’exemple B montre que les éléments positionnés en relatif se comportent de façon tout à fait identique à ceux positionnés en statique. Mais ce que vous ne savez peut‑être pas, c’est que les éléments qui ont la valeur relative sont comme Clark Kent : ils dissimulent de bien plus grands pouvoirs que leurs congénères statiques…

Pour débuter, nous pouvons attribuer l’une de ces décalages à un élément relatif : top, right, bottom ou left. À l’aide du balisage tiré de notre exemple précédent, appliquons un décalage à #box_2 :

#box_2 {
  position: relative;
  left: 200px;
  width: 200px;
  height: 200px;
  background: #44accf;
}

L’exemple C montre ce que donne ce positionnement avec relative. Nos trois blocs s’empilent gentiment, mais cette fois le bloc bleu (#box_2) s’écarte de 200 pixels du bord gauche. C’est ici que nous commençons à modifier la loi de la gravitation à notre guise. Le bloc bleu est toujours dans le flux du document (puisque les éléments s’empilent les uns sur les autres), mais observez le bloc vert en bas (#box_3) : il est placé sous le bloc bleu, alors même que celui‑ci n’est pas directement au‑dessus de lui. Quand nous utilisons un décalage pour déplacer un élément positionné en relatif, cela n’affecte pas les éléments qui le suivent. Le bloc vert reste placé comme si le bleu n’était pas décalé. Essayez ça avec des cubes en bois…

Autre super‑pouvoir de la valeur relative : la possibilité de créer un système de coordonnées pour ses éléments enfants. Un système de coordonnées est un point de référence pour les décalages. Souvenez‑vous de l’exemple C, notre bloc bleu (#box_2) n’est situé à l’intérieur d’aucun autre élément, donc le système de coordonnées qu’il utilise pour se décaler à 200 pixels de la gauche du document est le document lui‑même. Si nous plaçons l’élément #box_2 à l’intérieur de #box_1, nous obtiendrons un autre résultat, car #box_2 va se positionner relativement au système de coordonnées de #box_1. Pour l’exemple suivant, nous ne modifierons rien au CSS, mais nous allons retoucher notre code HTML pour déplacer #box_2 à l’intérieur de #box_1 :

<div id="box_1">
   <div id="box_2"></div>
</div>

L’exemple D montre ce que donne notre nouveau balisage. À cause du nouveau système de coordonnées, le bloc bleu calcule son décalage de 200 pixels à partir de la gauche du bloc rouge (#box_1) et non plus à partir du document. Cette pratique est plus courante quand les éléments se voient attribuer position: absolute — tel que vous auriez aimé construire vos tours.

Absolute : n’inporte où, n’inporte quand

Si la valeur relative se comporte comme Superman, alors la valeur absolute renvoie à Inception — un lieu où vous pouvez concevoir votre propre univers. Contrairement aux valeurs static et relative, un élément positionné de façon absolue est retiré du flux normal. Cela veut dire que vous pouvez le mettre où vous voulez, car il n’affectera ou ne sera affecté par aucun autre élément dans le flux. Voyez‑le comme un élément doté d’un grand morceau de velcro dans le dos. Il suffit de lui dire où se coller, et il va y rester. De la même façon que pour la valeur relative, les éléments positionnés en absolu vont répondre aux décalages. Vous pouvez placer un élément à top: 100px et left: 200px, et cet élément se mettra exactement à 100px du haut du document, et à 200px de son bord gauche. Voyons un exemple en utilisant quatre éléments :

#box_1 {
  position: absolute;
  top: 0;
  left: 0;
  width: 200px;
  height: 200px;
  background: #ee3e64;
}
#box_2 {
  position: absolute;
  top: 0;
  right: 0;
  width: 200px;
  height: 200px;
  background: #44accf;
}
#box_3 {
  position: absolute;
  bottom: 0;
  left: 0;
  width: 200px;
  height: 200px;
  background: #b7d84b;
}
#box_4 {
  position: absolute;
  bottom: 0;
  right: 0;
  width: 200px;
  height: 200px;
  background: #ebde52;
}

L’exemple E nous montre quatre boîtes, chacune située dans un coin de la fenêtre du navigateur. Comme nous avons fixé en absolute la position de chaque boîte, c’est comme si nous avions collé une boîte au velcro dans chaque coin de la fenêtre du navigateur. Si nous redimensionnons cette fenêtre, les boîtes resteront dans leurs coins respectifs. Si vous réduisez le navigateur de telle sorte que les boîtes se recouvrent, vous remarquerez qu’il n’existe aucune interaction : c’est parce qu’elles sont exclues du flux normal du document.

Tout comme les éléments placés de façon relative, ceux qui le sont de manière absolute créent un nouveau système de coordonnées pour les éléments enfants. L’exemple F modifie l’exemple E en plaçant un élément orange à l’intérieur de chaque boîte. Remarquez que les coordonnées de décalage fonctionnent par rapport à chaque élément parent.

Histoire de ne pas se faire doubler par d’autres valeurs de positionnement, la valeur absolute offre certaines fonctionnalités vraiment très pratiques en utilisant les propriétés de décalage. Si vous prenez deux de ces propriétés, voire toutes les quatre, vous pouvez étirer un élément sans lui définir de largeur ni de hauteur : il n’est limité que par son élément-parent, ou bien par le document lui‑même. Voyons cela en action. Si vous prenez le code suivant :

#box_1 {
  position: absolute;
  top: 10px;
  right: 10px;
  bottom: 10px;
  left: 10px;
  background: #44accf;
}
#box_2 {
  position: absolute;
  top: 20px;
  right: 20px;
  bottom: 20px;
  left: 20px;
  background: #ff9c34;
}

Dans l’exemple G, nous avons créé une bordure décalée de dix pixels par rapport au bord du document, et cela reste parfaitement fluide si on redimensionne la fenêtre : le tout est réalisé avec un positionnement et des décalages en absolute. Dans un autre exemple, nous pouvons créer une mise en page en deux colonnes qui occupe toute la hauteur du document. Voici la CSS :

#box_1 {
  position: absolute;
  top: 0;
  right: 20%;
  bottom: 0;
  left: 0;
  background: #ee3e64;
}

#box_2 {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 80%;
  background: #b7d84b;
}

L’exemple H montre une mise en page en deux colonnes occupant tout l’écran. Même s’il ne s’agit sans doute pas de la meilleure façon de concevoir une mise en page en deux colonnes, cela montre quand même toute la puissance de la valeur absolute. En réfléchissant un peu au‑delà, vous pouvez trouver de nombreuses applications utiles à position: absolute. Des manipulations du même genre n’exploitent qu’une seule valeur de décalage. Par exemple :

#box_1 {
  width: 200px;
  height: 200px;
  background: #ee3e64;
}
#box_2 {
  position: absolute;
  left: 100px;
  width: 200px;
  height: 200px;
  background: #44accf;
}

Dans l’exemple H2, regardez bien le bloc bleu. Remarquez que je n’utilise qu’un seul décalage, left: 100px;. Cela permet à l’élément #box_2 de maintenir sa position verticale, tout en s’éloignant de la gauche de 100 pixels . Si nous appliquions un second décalage de zéro par rapport au bord supérieur, nous verrions que notre bloc bleu (#box_2) est tiré vers le haut du document. On peut le voir ici, dans l’exemple H3 :

#box_2 {
  position: absolute;
  top: 0;
  left: 100px;
  width: 200px;
  height: 200px;
  background: #44accf;
}

Fixed : personne ne bouge !

Un élément auquel on a attribué position: fixed partage les mêmes règles qu’un élément positionné en absolu, mise à part que c’est la zone d’affichage (fenêtre du navigateur ou du périphérique) qui détermine le placement de l’élément « fixé » (fixed), et non pas un élément parent. D’autre part, un élément fixed ne défile pas avec le document. Il reste… fixe, quoi ! Voyons un exemple :

#box_2 {
  position: fixed;
  bottom: 0;
  left: 0;
  right: 0;
}

L’exemple I montre un pied de page (« footer ») avec à l’intérieur un texte de copyright. Ce pied de page constitue un élément fixe. Si vous faites défiler le document, vous verrez qu’il ne bouge pas. Remarquez que les propriétés de décalage left et right sont mises à zéro. Dans la mesure où la valeur fixed se comporte de la même façon que la valeur absolute, nous pouvons étirer la largeur de l’élément pour qu’il occupe toute la place du support de visualisation, tout en fixant cet élément en bas grâce à bottom: 0. Mais attention à fixed : son support dans les navigateurs anciens est plus mauvais qu’autre chose. Par exemple, d’anciennes versions d’Internet Explorer interprètent les éléments fixed comme des éléments avec static. Or vous savez maintenant que les éléments statiques ne se comportent pas comme les fixes, n’est‑ce pas ? Si vous voulez vraiment utiliser des éléments fixes dans une mise en page, il existe plusieurs solutions qui vous aideront à faire en sorte que votre élément se comporte comme prévu dans des navigateurs qui ne comprennent pas la valeur fixed.

Inherit : pour que rien ne change

Comme je l’ai évoqué au début de cet article, il y a cinq valeurs possibles pour la propriété position. La cinquième est inherit. Elle fonctionne comme l’indique son nom : l’élément hérite de la valeur de son élément parent. En principe, les éléments qui ont une valeur de positionnement n’héritent pas naturellement des valeurs de leurs parents, puisque la valeur static est assignée par défaut si aucune valeur de positionnement n’est indiquée. Mais vous pouvez saisir inherit ou bien la valeur de l’élément parent, et ainsi obtenir la même valeur.

Dans les faits

Assez de blabla et passons à l’action. Jetons un œil à un exemple de site web qui utiliserait toutes les valeurs de positionnement. L’exemple J montre la mise en page typique d’un site contenant un en-tête, la navigation, le contenu, et un pied de page. Voyons chaque élément l’un après l’autre pour parler de son positionnement et comprendre les choix qui ont été faits.

Commençons par notre élément #container. Il s’agit simplement de l’élément conteneur que j’utilise pour centrer notre contenu dans la fenêtre de visualisation. L’élément de navigation #nav est le premier élément inclus dans notre élément #container. Cet élément #nav ne reçoit aucune propriété de positionnement, donc par défaut, sa valeur sera static. Ça nous va très bien : nous n’avons aucun besoin de décaler cet élément, ni de créer par son biais de nouveau système de coordonnées. En revanche, c’est ce dont nous aurons besoin avec #content, notre prochain élément. C’est pourquoi nous lui avons appliqué une position relative.

Comme nous ne mettons ici en œuvre aucun décalage, la valeur de position n’a pas de réelle influence sur l’élément #content, mais nous l’avons placé là pour créer un nouveau système de coordonnées pour l’élément #callout (l’encadré latéral). Nous assignons position: absolute à notre élément #callout, et puisque son élément parent (#content) est placé en relative, les propriétés de décalage que nous appliquons à #callout se basent sur les coordonnées créées par #content. L’élément #callout utilise un décalage négatif de 80 pixels à droite pour tirer cet élément vers l’extérieur de l’élément parent qui le contient. De plus, j’ai employé sur l’élément #callout l’une des possibilités les plus cool que nous offre la valeur absolute : en situant les décalages en haut et en bas à 100px, j’ai étiré l’élément #callout qui prend maintenant toute la hauteur du document, moins un décalage de 100 pixels en haut et en bas.

Comme l’élément #callout a une valeur absolue, cela n’affecte aucun autre élément. Il va donc falloir ajouter un espacement (« padding ») à l’élément #content pour éviter que nos paragraphes ne disparaissent en‑dessous. Le fixer à 250px à droite maintient notre contenu bien visible pour nos lecteurs. Pour conclure, nous avons ajouté un pied de page avec une position fixed pour bien le garder en bas de la page. Au fur et à mesure que nous faisons défiler la page, le pied de page reste bien en place. Tout comme nous avons ajouté un espacement à #content pour éviter que nos paragraphes ne soient masqués, nous allons faire de même pour l’élément #footer car son comportement est similaire à un élément positionné avec absolute. En ajoutant 60px d’espacement inférieur à l’élément #content, nous nous assurons qu’il est possible de faire dérouler l’intégralité du document sans qu’aucun texte ne puisse se cacher sous l’élément #footer, comme ce devrait normalement être le cas.

Nous voilà maintenant avec une belle mise en page toute simple, composée d’un menu de navigation, d’un espace de contenu, d’une zone d’encadré et d’un pied de page, tout en ayant placé des éléments en static, relative, absolute et fixed. Dans la mesure où nous avons utilisé la valeur fixed dans cette mise en page, il faudra appliquer certaines techniques pour s’assurer que les navigateurs les plus anciens respecteront notre design.

Conclusion

Grâce à la puissance de la propriété position, vous allez pouvoir créer des mises en page en toute confiance. Fort heureusement, 80% des valeurs de la propriété position sont très bien interprétées dans les navigateurs récents comme dans les plus anciens. Seule la valeur fixed doit vous tenir en alerte. C’est en comprenant intimement le fonctionnement de ces valeurs que vous poserez votre CSS sur des bases solides, en n’ayant plus pour limite que votre imagination. Si tout va bien, l’époque où vous vous arrachiez les cheveux à tenter de régler des problèmes de positionnement à coups de devinettes est bel et bien révolue.

Note de la rédaction : Attention ! Dans l’exemple J, l’utilisation de position: absolute pose un problème d’ergonomie et d’accessibilité. Dans le code source, la div « callout » vient avant la suite de la div « content » alors qu’elle apparait après visuellement.

Quand on navigue dans la page en tabulant au clavier ou avec une revue d’écran, le curseur se placera dans la zone « callout », avant la suite de la zone « content ». Pour éviter ce problème, il suffit de placer la div « callout » en fin de div « content », et de donner à cette dernière une hauteur minimum suffisante pour que toute la div « callout » soit visible quand la div « content » est courte.

Plus d’informations dans le guide Accessiweb, critère 10.4

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : CSS Positioning 101
  • Auteur : Noah Stokes
  • Date de parution : 16 novembre 2010
  • Traduction : Frédéric Chotard
  • Date de traduction : mai 2011
  • Thèmes : CSS, Web design
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

La propriété border-image en CSS3

Par Estelle Weyl

Bien que ce ne soit pas vraiment une nouveauté pour les navigateurs, la propriété border-image est désormais disponible dans la spécification CSS3. border-image (littéralement : image de contour, NdT) offre une méthode pour ajouter des contours décoratifs à n’importe quel élément. Avec les propriétés de border-image, vous pouvez créer des contours décoratifs pour des éléments qui vont bien au-delà des simples coins arrondis, avec des images très légères ou même avec des dégradés.

La propriété border-image vous permet de prendre une petite image, de la découper virtuellement en neuf tronçons, et de disposer ou d’étirer les morceaux de votre petite image au sein d’un autre élément beaucoup plus grand.

Vous pouvez prendre une image et l’étirer sur toute la largeur d’un bouton ou d’une page entière.

Nous avons utilisé l’image de gauche comme image de contour (border-image) à appliquer à la div de droite : il s’agit d’en maintenir les coins, tout en étirant le centre de notre image de contour pour recouvrir l’ensemble de la div de droite.

Dans ce second exemple, au lieu d’étirer le milieu de l’image de contour, nous l’avons répété. On pourra déformer légèrement l’image si nécessaire afin de s’assurer qu’elle ne soit pas abîmée dans les navigateurs qui l’afficheront. Pour s’assurer que l’image ne soit pas « cassée », sa largeur doit être un multiple de la largeur de celle de la petite tranche découpée dans l’image de départ. Nous avons donc répété le haut, le bas et les côtés tout en maintenant les coins à l’identique, créant ainsi un effet de timbre.

Voyons maintenant comment prendre une image de fond (background image) puis la découper virtuellement, et ensuite effectuer soit une répétition, soit un étirement afin de recouvrir les contours et le fond de notre élément.

La propriété border-image est un raccourci qui permet de déclarer :

  • border-image-source :
  • border-image-slice :
  • border-image-width :
  • border-image-outset :
  • border-image-repeat :

La syntaxe pour ce raccourci doit être :

border-image: <source>
<slice {1,4}> / <width {1,4}> <outset> <repeat{1,2}>;

Pour l’instant, les navigateurs Opera, Firefox, Chrome et Safari supportent tous la propriété raccourcie border-image mais ne supportent aucune des propriétés individuelles qui constituent ce raccourci. Par conséquent, même si nous allons traiter des différentes propriétés qui définissent les images de contour, il vous faudra toujours utiliser le raccourci et non pas le détail expliqué ci-dessous.

border-image-source :

La source de l’image de contour est constituée de l’URL, du dégradé ou des données URI de l’image que vous souhaitez employer comme image de contour. Dans les exemples précédents, et même si la propriété détaillée n’est PAS supportée en elle-même, c’est comme si nous avions utilisé :

.boiteEnDegrade {
  border-image-source: url(degrade.png);
}
.timbre {
  border-image-source: url(timbre.gif);
}

Vous pouviez déjà utiliser des dégradés, des images codées en base64, des gifs, des jpegs, des pngs et même des images SVG comme images de fond : de la même façon, vous pouvez maintenant inclure tous ces types d’images comme images de contour.

border-image-slice :

La propriété border-image-slice définit jusqu’à quatre longueurs permettant d’indiquer la distance à partir de chaque coin de l’image, afin de couper ou trancher notre image de contour.
Les valeurs de la propriété border-image-slice correspondent à des décalages vers l’intérieur à partir des bords de l’image (respectivement les bords haut, droit, bas et gauche). Concrètement, avec les quatre traits que l’on définit, le navigateur divise l’image de contour originale en neuf zones : quatre coins, quatre bords et un milieu. Les quatre coins conservent leur taille initiale. Les cinq autres valeurs peuvent être étirées ou répétées, ou bien un mélange des deux (effet d’arrondi), en fonction des valeurs des autres propriétés border-image.

Les traits noirs sur les images ci-dessus indiquent comment les quatre traits que nous avons définis découpent notre image de contour.

Dans nos exemples, nous avons tranché l’image à 30px à l’intérieur de chaque côté de l’image en dégradé, et à 8 pixels de chaque côté de l’image en timbre.

Dans les exemples ci-dessus, bien que l’écriture détaillée ne soit PAS supportée, c’est comme si nous avions utilisé :

.boiteEnDegrade {
  border-image-slice: 30 30 30 30;
}
.timbre {
  border-image-slice: 8 8 8 8;
}

ou encore, dans la mesure où les valeurs sont répétées (à l’instar du haut-droite-bas-gauche pour les propriétés border ou padding), nous pouvons utiliser une valeur unique pour les quatre côtés :

.boiteEnDegrade {
  border-image-slice: 30;
}
.timbre {
  border-image-slice: 8;
}

Vous remarquez que nous n’avons précisé aucune unité de longueur. Si vous indiquez des longueurs pour les tranches de l’image, et que ces valeurs sont à interpréter en pixels, ne précisez pas l’unité employée. Mais si vous utilisez des valeurs relatives, indiquez le pourcentage. Dans notre exemple, nous aurions pu aussi utiliser ce qui suit :

.boiteEnDegrade {
  border-image-slice: 30%;
}
.timbre {
  border-image-slice: 26.7%;
}

Pour les images bitmap, les valeurs par défaut sont supposées être données en pixels. Pour les images vectorielles (SVG), les valeurs sont des coordonnées. Pour les pourcentages, utilisez le signe « pourcent » (%).

border-image-width

La propriété border-image-width donne la largeur du contour de l’élément. Si la propriété border-image-width est déclarée, elle prend le pas sur border-width dans la mesure où celle-ci est aussi déclarée. Si aucune des deux propriétés n’est déclarée, la valeur sera celle de border-width par défaut (« medium »), soit généralement 3px.

Ce raccourci n’est PAS supporté par Opera (dernière vérification faite sur la version 1024). Par ailleurs, la valeur automatique n’est supportée par aucun navigateur. Par conséquent, il est souvent recommandé d’inclure border-width comme une propriété séparée. En l’incluant dans le raccourci, c’est comme si nous avions déclaré :

.boiteEnDegrade {
border-image-width: 30px 30px 30px 30px;
}
.timbre {
border-image-width: 8px 8px 8px 8px;
}

ou encore, dans la mesure où les valeurs sont toutes identiques :

.boiteEnDegrade {
border-image-width: 30px;
}
.timbre {
border-image-width: 8px;
}

Nous avons donc jusqu’ici :

.boiteEnDegrade {
border-image: url(degrade.png) 30 / 30px;
}
.timbre {
border-image: url(timbre.gif) 8 / 8px;
}

Puisque le simple fait d’intégrer border-image-width dans le raccourci nous bloque pour Opera, il est recommandé de ne pas inclure cette propriété, et d’inclure à la place la valeur border-width de CSS2.

.boiteEnDegrade {
  border-width: 30px;
}
.timbre {
  border-width: 8px;
}

En prenant les mêmes largeurs pour border-image-width et border-image-slice, on obtient les meilleurs résultats d’image de contour, sans déformation. Néanmoins, il n’est pas obligatoire d’avoir des valeurs identiques. La tranche d’image sera étirée (ou contractée) à la largeur indiquée par border-image-width si ces valeurs ne concordent pas.

N’oubliez pas le box model ! Plus vous augmentez la valeur de border-image-width, plus votre élément va grandir.

border-image-outset

La propriété border-image-outset indique de combien la zone de l’image de contour peut s’étendre au-delà de l’espace de contour sur les quatre côtés. C’est une propriété qui n’est reconnue par aucun navigateur, et qui annulera même l’intégralité de la déclaration, donc à ne pas inclure pour le moment. La valeur par défaut est de zéro.

border-image-repeat

La propriété border-image-repeat vous permet de préciser de quelle façon les parties de l’image hors coins (c’est-à-dire les côtés et le milieu) sont répétées ou mises à l’échelle. La première valeur concerne le haut et le bas, la seconde les côtés droit et gauche. Si la seconde valeur est omise, les quatre côtés auront la même valeur.

Les spécifications définissent actuellement quatre valeurs possibles, mais seules trois sont bien interprétées. Stretch signifie que l’image ne doit pas être répétée en mosaïque, mais étirée afin de remplir la zone. Repeat signifie que l’image est répétée en mosaïque jusqu’à remplir la zone. Si la zone allouée pour la répétition de l’image n’est pas exactement divisible par la largeur de l’image, la dernière occurrence de l’image risque d’être coupée. Avec round, l’image est répétée en mosaïque pour remplir la zone, tout en mettant sa taille d’origine à l’échelle adaptée : elle risque de ne pas conserver son rapport largeur-hauteur, mais on est certain qu’elle ne sera pas coupée. Remarquez au passage que Webkit ne comprend pas la valeur round, et la remplace par repeat (ce qui vaut mieux, après tout, que de ne rien comprendre du tout...).

La valeur space n’est pas supportée actuellement, mais si c’était le cas, l’image de contour serait répétée autant de fois que nécessaire pour remplir l’espace offert avec chaque occurrence régulièrement espacée par du blanc, dans la mesure où la largeur n’est pas un multiple exact de celle de l’image de départ.

Dans nos exemples ci-dessus, nous avons utilisé stretch pour le dégradé et round pour le timbre. Il faut toujours étirer les dégradés avec stretch, car si vous les répétez avec repeat, cela produira des ruptures très visibles entre chaque image. De même, on peut avoir l’impression que repeat serait bien adapté pour le timbre, mais c’est impossible de savoir si l’image est exactement divisible par la largeur de notre design. La valeur round déforme très légèrement l’image, mais c’est mieux que de la voir découpée.

Si nous avions fait l’inverse, l’effet obtenu serait bizarre. Autant le haut et le bas peuvent employer au choix round, repeat ou stretch, autant les côtés droit et gauche ont absolument besoin de la valeur stretch :

L’écriture raccourcie pour border-image

Comme nous l’avons déjà mentionné, aucun navigateur ne supporte les propriétés détaillées définies plus haut, mais Opera, Firefox, Chrome et Safari comprennent la propriété raccourcie border-image préfixée. Maintenant que nous avons compris les composants de la syntaxe raccourcie, il nous reste à tout mettre ensemble.

La syntaxe correcte est :

border-image: <source>
<slice {1,4}> / <width {1,4}>  / <outset> <repeat{1,2}>;

Mais comme outset n’est pas interprété pour l’instant, nous pouvons ne pas l’intégrer :

border-image: <source>
<slice {1,4}> / <width {1,4}> <repeat{1,2}>;

Comme pour toutes les images de contour, nous avons découpé notre image dégradée en neuf tranches définies par la propriété border-image-slice. En général, les tranches ont la même largeur que border-width. Et puisque nous avons un dégradé, il nous faut étirer l’image et non la répéter pour éviter des transitions de couleur indésirables. Donc notre code sera comme ceci :

.boiteEnDegrade {
    border-image: url(degrade.png) 34 34 34 34 / 34px 34px 34px 34px stretch stretch;
}

Ce qu’on peut simplifier pour éviter les répétitions :

.boiteEnDegrade {
    border-image: url(degrade.png) 34  / 34px  stretch;
}

Comme Opera ne comprend pas border-image-width si on l’inclut dans le raccourci, on va l’indiquer séparément, puis on détaillera nos déclarations pour préciser les préfixes propres aux différents navigateurs :

.boiteEnDegrade {
   border-width: 34px;
  -moz-border-image: url(degrade.png) 34 / 34px  stretch;
  -webkit-border-image: url(degrade.png) 34 / 34px  stretch;
  -o-border-image: url(degrade.png) 34   stretch;
   border-image: url(degrade.png) 34 / 34px   stretch;
}

De même, notre effet de timbre est basé sur une image de timbre qu’on indique comme étant la border-image-source ; à l’arrivée nous devrons avoir une bordure de 8px de large, bordure qui devra se répéter mais sans se terminer par un fragment d’image sous peine d’abîmer tout notre design. Reste aussi le problème d’Opera avec border-width, et tous les préfixes propres aux différents navigateurs. Ce qui nous donne le code suivant :

.timbre {
    border-width: 8px;
   -webkit-border-image: url(timbre.gif) 8 / 8px round;
   -moz-border-image: url(timbre.gif) 8 / 8px round;
   -o-border-image: url(timbre.gif) 8  round;
    border-image: url(timbre.gif) 8 / 8px  round;
    }

Ressources

J’espère que vous avez désormais une meilleure compréhension de la façon de créer une image de contour. Voici quelques outils pour vous aider davantage :

  • les spécifications du W3C pour border-image ;
  • un outil pour créer du code CSS à partir de votre propre image de contour ;
  • une grille reprenant les propriétés que supporte ou non chaque navigateur ;
  • un outil de visualisation des images de contour.
Les images employées dans cet article servent à illustrer les effets obtenus avec border-image. Mais pour voir la propriété en action ainsi que le code employé, rendez-vous sur la page de démonstration.

Fiche technique

  • Article original : CSS3 Border-Image
  • Auteur : Estelle Weyl
  • Date de parution : 30 juin 2011
  • Traduction : Frédéric Chotard
  • Date de traduction : mai 2012
  • Thèmes : CSS, Design, Web design


Pompage.net - CSS : on reprend tout à zéro !

Les Portes Coulissantes de CSS

Par Douglas Bowman

Un des avantages de CSS rarement évoqué est la capacité de superposer des images d'arrière-plan, permettant de glisser l'une par-dessus l'autre pour créer certains effets. CSS2 en l'état requiert un élément HTML distinct pour chaque image de fond. Dans de nombreux cas, le balisage type pour des composants d'interface courants nous fournit déjà plusieurs éléments à utiliser.

L'un de ces cas est la navigation par onglets. Les onglets jouissent d'une popularité grandissante en tant que moyen de navigation primaire, et il est temps d'en reprendre le contrôle. Maintenant que CSS est largement supporté, nous pouvons améliorer la qualité et l'apparence des onglets sur nos sites. Vous savez probablement que CSS peut être utilisé pour apprivoiser une simple liste non ordonnée. Vous avez peut-être même déjà vu des listes habillées comme des onglets, ressemblant à quelque chose comme çeci :

[Exemple ordinaire d'onglets basés sur des CSS, avec des couleurs pleines et des coins carrés.]

Et si on pouvait prendre le balisage exact tel qu'utilisé pour les onglets ci-dessus, et les transformer en quelque chose comme çeci :

[Onglets stylisés utilisant des coins ronds et un ombrage en relief subtil.]

Avec quelques styles, nous le pouvons.

Où est l'innovation ?

Nombreux sont les onglets à base de CSS que j'ai vu souffrir des mêmes attributs génériques : des fonds de couleur tout carrés, parfois un contour, une bordure qui disparaît pour l'onglet actif, un changement de couleur en guise de rollover. C'est tout ce que CSS peut nous offrir ? Quelques boîtes et des couleurs unies ?

Avant que CSS ne soit plus largement adopté, on commençait à voir de nombreuses innovations dans la conception de navigations : des formes inventives, des fondus de couleurs maîtrisés, et l'imitation d'interfaces physiques du monde réel. Mais ces concepts reposaient lourdement sur des constructions complexes d'images textuelles, ou des imbrications multiples de tableaux. Tout redimensionnement du texte était impossible, ou provoquait des problèmes significatifs dans la mise en page.

Une navigation purement textuelle est bien plus facile à entretenir et se charge plus rapidement qu'une navigation en images. De même, bien qu'on puisse ajouter des attributs alt à chaque image, le texte pur est encore plus accessible puisqu'il peut être redimensionné par les utilisateurs à la vision déficiente. Il n'est pas étonnant que la navigation à base de texte seul, stylée avec des CSS, resurgisse dans le web design. Mais la plupart des principes d'onglets basés sur CSS sont visuellement des retours en arrière par rapport à ce que nous avions l'habitude de faire (rien en tout cas qu'on inclurait dans un portfolio). Une technologie à l'adoption récente (comme CSS) devrait permettre de créer quelque chose de mieux, sans perdre la qualité de design de nos précédents onglets bidouillés en tableaux et en images.

La techniques des Portes Coulissantes

En utilisant deux images d'arrière-plan distinctes, nous pouvons créer des composants d'interface élégamment taillés, réellement flexibles, qui se contractent et se dilatent en même temps que la taille du texte. Il suffit d'une image à gauche, et d'une à droite. Pensez-y comme à des portes coulissantes qui ferment une entrée. Les portes se rejoignent et se recouvrent de plus en plus pour remplir un espace étroit, ou s'écartent en se recouvrant de moins en moins pour remplir un espace plus large, comme sur le schéma ci-dessous :

[Ce schéma montre deux jeux de portes; Le premier jeu est pressé ensemble pour prendre moins de place. Le deuxième jeu est espacé pour occuper un espace plus grand.]

Avec ce modèle, une image recouvre une partie de l'autre. Si on assume que nous avons un élément unique sur les bords extérieurs de chaque image, comme le coin arrondi d'un onglet, nous voudrons éviter que l'image de devant n'obscurcisse complètement celle de derrière. Pour s'en assurer, rendons l'image de premier plan (celle de gauche pour cet exemple) la moins large possible. Mais gardons-la juste assez grande pour révéler l'élément unique de son côté. Si les coins externes sont arrondis, nous devrions rendre l'image de premier plan juste assez large pour contenir la portion courbe du dessin :

[Le schéma montre une image isolée d'un côté gauche étroit avec un coin supérieur gauche arrondi, puis répète la même image placé devant une image d'un côté droit avec un coin supérieur droit arrondi.]

Si l'objet devait dépasser la largeur illustrée ci-dessus, à cause d'un texte long ou d'un changement de corps de police, les images s'éloigneront l'une de l'autre, créant un vilain trou. Nous devons donc faire un choix arbitraire sur la fourchette de redimensionnement envisagée. Jusqu'à quelle largeur l'objet risque t-il de grandir en fonction du redimensionnement du texte dans un navigateur ? Nous devrions probablement compenser un agrandissement d'au moins 300%. Pour cela il faut étendre l'image d'arrière-plan. Pour l'exemple d'aujourd'hui nous allons faire une image de fond (celle de droite) de 400x150 pixels, et une image de premier plan de 9x150 pixels.

Gardez à l'esprit que les images d'arrière-plan apparaissent seulement dans le «passage » disponible de l'élément auquel elles sont appliquées (la zone de contenu + le padding). Les deux images sont ancrées aux coins extérieurs de leurs éléments respectifs. Les parties visibles de ces images de fond s'assemblent à l'intérieur du passage pour ressembler à un onglet :

[Le schéma montre les deux images avec une hauteur supplémentaire ajoutée à la partie inférieure. L'image du côté droit se voit aussi ajouter une largeur supplémentaire à gauche. Les seules portions qui restent visibles s'assemblent parfaitement pour former l'illusion d'un onglet.]

Si l'onglet est forcé vers une taille plus grande, les images coulissent vers l'extérieur, remplissant un passage plus large, et révélant un peu plus de chaque image :

Dans cet exemple, j'ai utilisé Photoshop pour créer deux images d'onglets doux, légèrement en relief, ceux qui sont présentés au début de cet article. Pour l'un des onglets, le dégradé a été éclairci et les bords assombris - la version claire sera utilisée pour représenter l'onglet actif. À cause du modèle de cette technique pour les images gauche et droite de l'onglet, nous devons étendre la zone couverte par l'image et la couper en deux morceaux :

[Images des côtés gauche et droit]

Il faut opérer de même avec l'image plus claire de l'onglet actif. Quand les quatre images sont créées (1, 2, 3, 4), nous pouvons passer au balisage et aux CSS pour nos onglets.

Création des onglets

À mesure que vous explorez la création de listes horizontales avec CSS, vous noterez au moins deux méthodes pour arranger un groupe d'éléments en ligne. Chacune comporte ses avantages et ses inconvénients. Chacune demande de devoir gérer certains aspects un peu louches de CSS qui peuvent rapidement devenir déroutants. L'une utilise les boîtes en-ligne (inline), l'autre requiert float.

La première méthode - probablement la plus courante - change l'affichage de chaque item de liste en display: inline. La méthode en-ligne est attirante de par sa simplicité. Toutefois, appliquée à la technique des Portes Coulissantes, elle cause quelques problèmes d'affichage dans certains navigateurs. La deuxième méthode, sur laquelle nous allons nous concentrer, utilise float pour placer chaque item de liste sur une ligne horizontale. float peuvt s'avérer aussi tout aussi frustrant que la méthode en-ligne. Son comportement apparemment incohérent échappe à toute logique. Pourtant, une compréhension basique de la manière de gérer de multiples éléments flottants permet de faire des merveilles.

Nous allons imbriquer plusieurs éléments flottants dans un élément conteneur, lui aussi flottant. Il faut faire cela pour que le parent flottant englobe complètement les éléments flottants intérieurs. De cette manière, nous pouvons ajouter une couleur de fond et/ou une image derrière nos onglets. Il est important de se souvenir que l'élément suivant directement nos onglets doit réinitialiser sa propre position en utilisant la propriété CSS clear. Cela empêche les onglets flottants d'affecter la position d'autres éléments dans la page.

Commençons avec le balisage suivant :

  <div id="header">
    <ul>

      <li><a href="/traduction/portescoulissantes#">Home</a></li>
      <li id="current"><a href="/traduction/portescoulissantes#">News</a></li>
      <li><a href="/traduction/portescoulissantes#">Products</a></li>

      <li><a href="/traduction/portescoulissantes#">About</a></li>
      <li><a href="/traduction/portescoulissantes#">Contact</a></li>
    </ul>

  </div>

En réalité, le div #header pourrait aussi contenir un logo et un champ de recherche. Pour notre exemple, nous allons raccourcir la valeur de href dans chaque ancre. Evidemment, ces valeurs devraient normalement contenir des adresses de fichiers ou de répertoires.

Commençons à habiller nos listes en flottant le conteneur #header. Cela permet de s'assurer que le conteneur «contient » effectivement les items de liste qui seront aussi flottants. Puisque l'élément est flottant, nous devons aussi lui assigner une largeur de 100%. Une couleur de fond jaune est temporairement ajoutée pour vérifier que le parent s'étire sur la totalité de la zone derrière les onglets. Définissons aussi quelques propriétés de texte par défaut, nous assurant que tout ce qui est à l'intérieur sera identique :

  #header {
    float:left;
    width:100%;
    background:yellow;
    font-size:93%;
    line-height:normal;
    }

Pour l'instant, établissons aussi les valeurs par défaut de margin et padding pour la liste et ses éléments à "0", et enlevons les puces. Chaque item de liste est aussi flottant à gauche :

  #header ul {
    margin:0;
    padding:0;
    list-style:none;
    }
  #header li {
    float:left;
    margin:0;
    padding:0;
    }

Transformons les ancres en éléments de type bloc pour en garder le contrôle sans nous soucier du modèle en-ligne :

  #header a {
    display:block;
    }

Ensuite, ajoutons notre image de fond du côté droit aux items de liste (les changements/ajouts sont en gras) :

  #header li {
    float:left;
    background:url("norm_right.gif")
      no-repeat right top;

    margin:0;
    padding:0;
    }

Avant d'ajouter l'image du côté gauche, faisons une pause pour voir où nous en sommes, dans l'exemple 1. (Dans le fichier exemple, ignorez les règles que j'ai appliqué à body. Elles donnent seulement des valeurs de base pour les marges, le padding, les couleurs et le texte.)

- - -

Nous pouvons maintenant placer l'image de gauche devant celle de droite en l'appliquant à l'ancre (notre élément interne). Ajoutons le padding en même temps, pour étendre l'onglet et décoller le texte des bords :

  #header a {
    display:block;
    background:url("norm_left.gif")
      no-repeat left top;
    padding:5px 15px;
    }

Cela nous donne l'exemple 2. Notez comme les onglets ont commencé à prendre forme. À cette étape, un mot pour les utilisateurs perdus d'IE5/Mac, qui se demandent Mais qu'est-ce qui se passe ici ? Les onglets sont empilés verticalement et s'étirent sur tout l'écran ! Ne vous inquiétez pas, on s'occupe bientôt de vous. Pour l'instant faites de votre mieux pour suivre, ou passez temporairement sur un autre navigateur si vous le pouvez, et soyez sûrs que nous traiterons rapidement le problème.

- - -

Maintenant que les images de fond sont en place pour les onglets normaux, nous devons changer les images utilisées pour l'onglet actif. Faisons-le en ciblant l'item de liste dont id="actif" et l'ancre qu'il contient. Puisque nous n'avons pas besoin d'altérer d'autres aspects de l'arrière plan que l'image, utilisons la propriété background-image :

  #header #current {
    background-image:url("norm_right_on.gif");
    }
  #header #current a {
    background-image:url("norm_left_on.gif");
    }

Nous avons besoin d'une sorte de bordure en-dessous de nos onglets. Mais appliquer une propriété border au conteneur #header ne nous permettra pas de «fondre » l'onglet actif dans cette bordure. Au lieu de cela, créons une nouvelle image avec la bordure que nous voulons inclure sous cette image. Pendant que nous y sommes, ajoutons un subtil dégradé pour qu'elle ressemble à ceci :

Appliquons cette image à l'arrière plan de notre conteneur #header (au lieu de la couleur jaune que nous avions), poussons l'image de fond en bas de l'élément, et utilisons une couleur de fond assortie au haut de cette nouvelle image. Dans le même temps, supprimons le padding de l'élément body que j'avais inséré à l'origine, et appliquons 10 pixels de padding au côtés haut, gauche, et droit de ul :

  #header {
    float:left;
    width:100%;
    background:#DAE0D2 url("bg.gif")
      repeat-x bottom;

    font-size:93%;
    line-height:normal;
    }
  #header ul {
    margin:0;
    padding:10px 10px 0;
    list-style:none;
    }

Pour compléter l'effet d'onglet, nous devons fondre l'onglet actif dans la bordure, comme mentionné ci-dessus. On pourrait appliquer border-bottom à nos onglets, dans une couleur assortie à celle de la bordure de l'image de fond de #header, puis qu'on passerait en blanc pour l'onglet actif. Cependant, cette méthode provoquerait un minuscule décalage, dérangeant pour une précision au pixel près. Au lieu de cela, si nous modifions le padding des ancres, nous pouvons créer des coins parfaitement équarris à l'intérieur de l'onglet actif, comme illustré dans l'exemple agrandi ci-dessous :

[Agrandissement des deux versions d'onglets, la première montrant un minuscule décalge de 1 pixel dû à l'utilisation de border-bottom, la deuxième montrant an angle droit parfait.]

Accomplissons ceci en diminuant d'un pixel le padding-bottom de l'ancre normale (5px - 1px = 4px), puis en rajoutant ce pixel à l'ancre active :

  #header a {
    display:block;
    background:url("norm_left.gif")
      no-repeat left top;
    padding:5px 15px 4px;
    }
  #header #current a {
    background-image:url("norm_left_on.gif");
    padding-bottom:5px;

    }

Le changement permet à la bordure inférieure d'apparaître pour les onglets normaux, tout en la cachant pour l'onglet actif. Ceci amène notre code à l'exemple 3.

Touches finales

Vos yeux de lynx auront noté des coins blancs apparaissant dans l'exemple précédent. Ces coins opaques empêchent pour l'instant l'image de fond de transparaître à travers le coin gauche de l'image de premier plan. En théorie, nous pourrions essayer d'accorder les coins des images d'onglets à une partie du fond derrière elles. Mais nos onglets peuvent s'agrandir en hauteur, ce qui pousse l'arrière plan vers le bas en décalant la couleur que nous voulions assortir. Changeons plutôt les images, en rendant transparents les coins de nos onglets. Si les courbes sont lissées, la transparence sera choisie d'après une moyenne de la couleur de fond derrière elles.

Maintenant que les coins sont transparents, un morceau de l'image de droite apparaît à travers le coin de l'image de gauche. Pour compenser ceci, ajoutons à l'item de liste une petite quantité de padding gauche équivalent à la largeur de l'image de gauche (9px). Du padding ayant été ajouté à l'item de liste, nous devons en enlever autant à l'ancre pour conserver le centrage du texte (15px - 9px = 6px) :

  #header li {
    float:left;
    background:url("right.gif")
      no-repeat right top;
    margin:0;
    padding:0 0 0 9px;
    }
  #header a {
    display:block;
    background:url("left.gif")
      no-repeat left top;
    padding:5px 15px 4px 6px;

    }

Toutefois nous ne pouvons pas en rester là, parce que notre image de gauche est maintenant repoussée du bord gauche de l'onglet par les 9 pixels que nous venons d'ajouter. Maintenant que les bords intérieurs des passages visibles droit et gauche s'accolent, nous n'avons plus besoin de garder l'image de gauche au premier plan. Nous pouvons donc intervertir l'ordre des deux images de fond, en l'appliquant aux éléments opposés. Nous devons aussi intervertir les images utilisées pour l'onglet actif :

  #header li {
    float:left;
    background:url("left.gif")
      no-repeat left top;
    margin:0;
    padding:0 0 0 9px;
    }
  #header a, #header strong, #header span {
    display:block;
    background:url("right.gif")
      no-repeat right top;
    padding:5px 15px 4px 6px;
    }
  #header #current {
    background-image:url("left_on.gif");
    }
  #header #current a {
    background-image:url("right_on.gif");
    padding-bottom:5px;
    }

Cela fait, nous arrivons à l'exemple 4. Notez que les manipulations nécessaires pour rendre les coins transparents créent un petit espace mort sur le côté gauche de l'onglet quand il n'est pas cliquable. L'espace mort est en dehors de la zone de texte, mais il est légèrement visible. Utiliser des images transparentes pour chaque côté de nos onglets ne sera pas nécessaire. Si nous ne préférons pas avoir ce petit espace mort, nous devons utiliser une couleur pleine derrière les onglets, puis utiliser cette couleur pour le coin de nos images d'onglets au lieu de les rendre transparents. Pour l'instant, nous allons conserver nos coins transparents.

- - -

Pour les modifications restantes, nous allons faire plusieurs changements d'un seul coup : passer en gras tous les textes d'onglets, donner une couleur marron au texte normal, colorer le texte d'onglet actif en gris foncé, enlever les soulignements de liens, et passer la couleur de texte des liens survolés dans le même gris foncé. Tous les ajouts et modifications sont maintenant présents dans l'exemple 5.

Une bidouille pour la cohérence

Après l'exemple 2, nous avons identifié un problème avec IE5/Mac où chaque onglet s'étire sur toute la largeur du navigateur, forçant chacun à s'empiler verticalement sur le suivant. Pas tout à fait l'effet que nous recherchions.

Dans la plupart des navigateurs, flotter un élément le réduit à la plus petite taille possible de son contenu. Si un élément flottant contient (ou est) une image, sa taille diminuera jusqu'à celle de l'image. S'il ne contient que du texte, il rétrécira jusqu'à la largeur du mot le plus long.

Le problème survient pour IE5/Mac quand un élément de type bloc à largeur automatique est inséré dans un élément flottant. Les autres navigateurs vont rétrécir l'élément flottant à sa plus petite taille possible, indépendamment de l'élément de-type bloc qu'il contient. Mais IE5/Mac n'applique pas ce rétrécissement. Au contraire, il étend le flottement et l'élément de type bloc à toute la largeur disponible. Pour contourner ce problème, nous devons flotter l'ancre, mais seulement pour IE5/Mac, de peur de perdre les autres navigateurs. Modifions d'abord la règle existante pour flotter l'ancre. Puis nous nous servirons du Commented Backslash Hack pour cacher une nouvelle règle à IE5/Mac annulant le flottement dans tous les autres navigateurs :

  #header a {
    float:left;

    display:block;
    background:url("right.gif")
      no-repeat right top;
    padding:5px 15px 4px 6px;
    text-decoration:none;
    font-weight:bold;
    color:#765;
    }
  /* Commented Backslash Hack
     Cache des règles à IE5-Mac \*/
  #header a {float:none;}
  /* Fin du hack IE5-Mac */

Les navigateurs IE5/Mac devraient maintenant afficher les onglets comme prévu, selon l'exemple 6. Rien ne devrait avoir changé pour les autres navigateurs. Notez que IE5.0/Mac souffre d'un nombre important de bugs de rendus qui ont été corrigés dans la mise à jour vers IE5.1. Pour cette raison, la technique des Portes Coulissantes peine dans la version 5.0 à un point que je renonce à essayer de bidouiller. La mise à jour vers IE5.1/Mac étant disponible depuis un certain temps maintenant, le pourcentage de Macs OS9 comportant encore IE5.0 devrait s'être réduit à peau de chagrin.

Variations

Nous venons de parcourir la technique des Portes Coulissantes pour créer une navigation par onglets avec du texte pur, balisée avec une liste de liens non ordonnée, altérée grâce à quelques styles maison. Elle se charge vite, s'entretient facilement, et le texte peut être redimensionné vers le haut ou le bas de manière significative avant de casser la mise en page. Faut-il encore mentionner à quelle point cette technique est suffisamment flexible pour créer n'importe quel type de navigation d'allure sophistiquée ?

Les applications de cette technique ne sont limitées que par votre imagination. Notre exemple final représente une possibilité, mais ne laissez pas un seul exemple brider vos idées.

Par exemple, les onglets n'ont pas besoin d'être symétriques. J'ai rapidement créé une Version 2 de ces onglets, qui évitent le style 3D ombré en faveur de couleurs pleines, de coins angulaires, et d'un côté gauche plus large et détaillé. On peut changer l'ordre des images droite/gauche, selon le design, comme le montre la Version 2. Avec une bonne préparation et quelques manipulations d'image élaborées, on pourrait abandonner la bordure inférieure pour assortir les images des onglets au fond général derrière eux, comme le montre ma version 3 à l'inspiration Arts-Déco. Si votre navigateur permet le changement de styles à la volée, vous pouvez même visualiser ce fichier maître et basculer entre les trois versions différents en alternant les feuilles de styles.

D'autre effets que nous ne couvrons pas ici pourraient être rajoutés. Dans l'exemple de cet article, j'ai changé la couleur de texte pour l'état survolé, mais des images entières pourraient être interverties pour créer des rollovers intéressants. À chaque fois que deux éléments HTML imbriqués préexistent dans le balisage, CSS peut être utilisé pour des effets de couches d'images que nous n'avons même pas encore commencé à imaginer. Nous avons créé dans cet exemple une ligne horizontale d'onglets, mais les Portes Coulissantes pourraient être utilisées dans beaucoup d'autres situations. Qu'allez vous en faire ?


Pompage.net - CSS : on reprend tout à zéro !

Les Portes Coulissantes de CSS - Chapitre II

Par Douglas Bowman

Le Chapitre I des Portes Coulissantes de CSS vous a présenté une nouvelle technique pour créer des éléments d'interface visuellement percutants à base de simple balisage sémantique. Dans le Chapitre II, nous allons pousser la technique encore plus loin. Si vous n'aviez pas encore lu la première partie de cet article, il n'est pas trop tard.

Nous couvrirons dans ce chapitre un nouveau scénario où aucun onglet n'est actif, nous combinerons les Portes Coulissantes avec un rollover utilisant une seule image, nous fournirons un correctif pour la surface cliquable dans IE/Win, et nous suggérerons une méthode alternative de ciblage des onglets. Nous allons nous dispenser d'un récapitulatif de la technique de base (voyez le Chapitre I si besoin) pour sauter immédiatement dans l'action.

Pas d'onglet actif

Dans le Chapitre I, nous n'avons pas prévu le cas où aucun onglet ne serait actif. Un processus d'enregistrement par exemple, ou des pages contenant des informations légales, ne rentrent dans aucune des catégories représentées par les onglets. Si aucun d'entre eux n'est stylé en tant qu'onglet actif, la règle qui ajoute 1 pixel supplémentaire de padding-bottom ne sera pas utilisée. Du coup, les onglets cacheront la ligne courant le long de leur bord inférieur.

Le problème peut être facilement réglé en ajoutant un border-bottom de 1 pixel sous tous les onglets non actifs, puis en enlevant le border-bottom dans le cas ou un onglet actif existe :

#header li {
  float:left;
  background:url("left.gif")
    no-repeat left top;
  margin:0;
  padding:0 0 0 9px;
  border-bottom:1px solid #765;
  }
#header #current {
  background-image:url("left_on.gif");
  border-width:0;
  }

Le résultat de notre changement de style, quand le menu ne comporte aucun onglet actif, peut être vu dans l'exemple 7.

Rollovers à une seule image

Dans un souci de simplicité, nous avons intentionnellement écarté le sujet des rollovers du Chapitre I. Maintenant que la technique de base est maîtrisée, nous pouvons commencer à la combiner avec d'autres pour étendre l'utilité et le comportement de notre interface.

Jusqu'à récemment, implémenter n'importe quel effet de survol - que ce soit avec JavaScript ou CSS - revenait à créer deux jeux d'images : un pour l'état normal, et un autre pour l'état survolé. Pour éviter le délai causé par le téléchargement séparé de chaque images, de nombreuses méthodes existaient pour pré-charger les images nécessaires dans le cache du navigateur. Petr Stanicek (alias «Pixy ») nous montre dans «Rollovers rapides, sans pré-chargement » comment combiner les deux états (normal et survolé) en une seule image, éliminant le besoin d'un pré-chargement.

Dans notre exemple, empilons nos deux images de gauche l'une au-dessus de l'autre pour combiner l'état normal et l'état survolé en une nouvelle image. Effectuons le même travail pour l'image de droite. Les images de 150 pixels de haut à l'origine en font maintenant 300. Nous nous retrouvons avec left_both.gif et right_both.gif. Avec ces nouvelles images, nous pouvons profiter de la propriété CSS background-position pour rendre visible la bonne portion de l'image quand l'utilisateur survole un onglet.

[Quand la nouvelle image combinée est positionné en haut du passage, l'état normal est visible. Quand nous décalons l'image vers le haut, l'état survolé devient visible.]

Remplaçons par ces nouvelles images celles utilisées pour l'item de liste et l'ancre, en gardant les mêmes positions :

#header li {
  float:left;
  background:url("left_both.gif")
    no-repeat left top;
  margin:0;
  padding:0 0 0 9px;
  border-bottom:1px solid #765;
  }
#header a {
  float:left;
  display:block;
  background:url("right_both.gif")
    no-repeat right top;
  padding:5px 15px 4px 6px;
  text-decoration:none;
  font-weight:bold;
  color:#765;
  }

La propriété background-position doit se voir spécifier deux valeurs, horizontale et verticale, dans cet ordre exact. Nous ne pouvons pas combiner des mots-clé (left, right, top, etc.) comme nous l'avons fait avec les valeurs fixes ou en pourcentages. En spécifiant les positions de l'état survolé, nous éviterons donc entièrement les mots-clé. Utilisons 0% pour que le bord gauche de l'image de gauche soit positionné contre le côté gauche du «passage », et 100% pour que l'image de droite fasse l'inverse.

Comme nous connaissons exactement la hauteur à laquelle commence chaque état de la nouvelle image, nous pouvons précisément positionner les images de fond en pixels. Les 150 pixels supérieurs de ces images contiennent l'état normal, et les 150 pixels inférieurs l'état survolé. Donc, pour les deux rollovers, repoussons simplement les images de fond vers le haut en appliquant une valeur négative de 150px. Doublons aussi les sélecteurs de la première règle pour n'avoir à spécifier la couleur de texte qu'une seule fois :

#header li:hover, #header li:hover a {
  background-position:0% -150px;
  color:#333;
  }
#header li:hover a {
  background-position:100% -150px;
  }

Nous pouvons utiliser le même principe d'images combinées pour l'onglet actif. Au lieu de spécifier une nouvelle image comme auparavant, utilisons simplement les mêmes valeurs décalées de l'état survolé :

#header #current {
  background-position:0% -150px;
  border-width:0;
  }
#header #current a {
  background-position:100% -150px;

  padding-bottom:5px;
  color:#333;
  }

Implémenter des rollovers n'est pas plus difficile que ça. Admirez-les en action dans l'exemple 8. Nous avons réduit le nombre total d'images utilisées de 5 (2 de gauche, 2 de droite, et 1 d'arrière-plan derrière les onglets) à 3 (1 de gauche, 1 de droite, 1 arrière-plan), en ayant éliminé le besoin d'un pré-chargement.

Si vous avez suivi l'avancement des travaux sur Internet Explorer (Windows ou Mac), vous aurez sûrement noté que les effets de rollover, comme implémentés ci-dessus, ne fonctionnent pas. IE n'applique la pseudo-classe :hover qu'aux éléments d'ancre, et à rien d'autre. Pour pouvoir changer les deux images de la technique des Portes Coulissantes, nous devrions insérer un élément supplémentaire (comme un span) à l'intérieur de l'ancre, et descendre toutes nos règles de style d'un élément (les règles d'item de liste passeraient à l'ancre, et les règles de l'ancre passeraient au span).

Nous n'analyserons pas en détail les ajustements nécessaires pour faire marcher l'effet de rollover dans IE. Mais afin de prouver qu'ils sont possibles, ces changements ont été démontrés dans l'exemple 8a. Comme vous le voyez, déplacer le rôle de chaque élément élimine aussi le petit espace mort mentionné dans le Chapitre I, parce que l'ancre contient maintenant l'intégralité de l'onglet.

Les rollovers ont généralement une fonction (plus ou moins) décorative. Certains d'entre vous décideront peut-être que les avantages d'un rollover fonctionnel dans Internet Explorer ne valent pas un surcroît de balisage. D'autres penseront que les span supplémentaires sont un maigre prix à payer pour obtenir des rollovers qui fonctionnent dans tous les navigateurs populaires, et pour éliminer l'espace mort des exemples précédents. À vous de choisir.

Correctif de surface cliquable

Comme dans le cas de nos exemples d'onglets du Chapitre I, les liens de navigation peuvent devenir des éléments de type bloc et recevoir un padding supplémentaire pour augmenter la surface cliquable du lien. La surface visuelle est le plus souvent remplie d'une couleur de fond (ou d'une image dans notre cas) impliquant que l'utilisateur peut cliquer n'importe où dans cette zone, et pas juste sur le contenu du lien. Dans la plupart des navigateurs, quand un élément ancre est changé en élément de type bloc (via CSS) et qu'un padding supplémentaire y est ajouté, ses surfaces visuelles et cliquables augmentent simultanément pour couvrir le contenu et le padding du lien. Malheureusement, IE/Win étend uniquement la surface visuelle, confinant la surface cliquable au contenu de l'ancre, sans inclure son padding :

[Dans la plupart des navigateurs la surface cliquable s'étend à toute la zone visible de l'onglet, mais Internet Explorer pour Windows ne rend cliquable que le texte.]

Dans le Chapitre I (et juste après l'exemple 8 ci-dessus), nous avons brièvement mentionné une petite quantité d'espace mort sur le côté gauche de l'onglet, causée par la transition vers les images de coins transparents. Nous avons aussi noté les conditions requises pour éviter cet espace mort. Toutefois, le Chapitre I évitait le sujet de la surface cliquable réduite dans IE/Win. Ce navigateur (versions 6.02 et inférieures) souffre de plusieurs bugs dans son implémentation de CSS. L'un de ces bugs produit des problèmes inattendus - et parfois inaperçus - dans l'ergonomie et l'accessibilité des navigations basées sur CSS.

Spécifier une largeur ou une hauteur pour l'ancre forcera magiquement IE à étendre aussi la surface cliquable. Mais procéder ainsi inhibe la taille flexible de notre «passage » dans d'autres navigateurs. Pour notre exemple d'onglets, vous pourriez penser que les unités en 'ems' sont envisageables pour spécifier largeur ou hauteur. Cela baserait la taille de nos onglets sur celle déjà héritée par le texte qu'ils contiennent. Mais spécifier une hauteur à une ancre rend IE/Win maboul. Et à moins d'utiliser une fonte monospace pour notre texte d'onglets, une largeur en ems brisera l'équilibre entre la largeur des onglets et le texte lors de redimensionnement (sans parler de la difficulté à déterminer une largeur appropriée pour chaque morceau de texte, puis à re-spécifier la largeur chaque fois que le texte est modifié).

Heureusement pour nous, nous pouvons exploiter une faille différente dans l'implémentation de CSS par IE, pour forcer l'extension de la surface cliquable dans ce navigateur sans devoir assumer une largeur arbitraire. Il suffit de spécifier une petite largeur pour l'ancre. La plupart des navigateurs prendront en compte - et respecteront - la valeur de width pour un élément de type bloc, même si le contenu de cet élément ne tient pas dans la largeur spécifiée. L'élément rétrécira à la largeur demandée, même si le texte à l'intérieur doit pour cela en déborder. Mais IE/Win ne contractera l'élément que jusqu'à la longueur du morceau de texte insécable le plus long.

Donc, même si nous donnons une largeur à l'ancre (comme 0.1em), IE/Win permettra toujours à celle-ci d'être aussi large que le texte qu'elle contient. parallèlement, IE étendra aussi la surface cliquable pour qu'elle remplisse tout l'onglet :

#header a {
  float:left;
  display:block;
  width:.1em;
  background:url("right.gif") no-repeat right top;
  padding:5px 15px 4px 6px;
  text-decoration:none;
  font-weight:bold;
  color:#765;
  }

Cette manipulation ne répond à aucune logique, les deux concepts étant directement contradictoires. Mais cela fonctionne, et corrige la surface cliquable pour IE/Win. Nous devons garder à l'esprit que les autres navigateurs honorent la valeur de width, et tenteront de contracter la largeur de chaque onglet à 0.1em + padding. Heureusement, IE/Win (6.0 et moins) ne comprend pas non plus le sélecteur CSS d'enfant - nous pouvons donc en utiliser un pour réinitialiser la largeur de l'ancre à "auto" pour tous les autres navigateurs, permettant aux onglets de s'étendre et de se contracter normalement :

#header > ul a {width:auto;}

L'exemple 9 corrige le problème de surface cliquable dans IE/Win, et son triste petit hack reste invisible aux autres navigateurs.

Cibler des onglets

Tous les exemples du Chapitre I utilisaient un id appliqué à un item de liste pour altérer l'apparence de l'onglet actif. La conséquence du déplacement de l'id d'un item de liste à un autre est un concept facile à appréhender, même pour quelqu'un de nouveau aux CSS. Mais un moyen différent de cibler l'onglet actif pourrait s'avérer plus efficace dans de nombreux cas, même s'il faut pour cela rajouter un petit peu de balisage.

Au lieu d'utiliser un unique id="current"pour identifier l'onglet actif dans le balisage, nous pouvons appliquer des id uniques à chaque item de liste, comme ceci :

<div id="header">
  <ul>
    <li id="nav-home"><a href="/traduction/portescoulissantes2#">Home</a>

        </li>
    <li id="nav-news"><a href="/traduction/portescoulissantes2#">News</a>
        </li>
    <li id="nav-products"><a href="/traduction/portescoulissantes2#">Products</a>

        </li>
    <li id="nav-about"><a href="/traduction/portescoulissantes2#">About</a>
        </li>
    <li id="nav-contact"><a href="/traduction/portescoulissantes2#">Contact</a>

        </li>
  </ul>
</div>

Nous pouvons aussi appliquer un id à un élément conteneur (comme body). La valeur de l'identifiant correspond à une rubrique à laquelle appartient la page. Cet id de body peut aussi être utilisé pour ajouter des styles spécifiques à la rubrique dans d'autres parties de la page. Avec des id aux deux endroits, nous pouvons altérer l'apparence d'un onglet, en particulier s'il satisfait aux conditions des sélecteurs descendants. Plutôt que d'utiliser #current dans notre sélecteur, combinons les id de body et des items de liste pour établir les conditions dans lesquelles un onglet est considéré comme actif :

#home #nav-home, #news #nav-news,
#products #nav-products,
#about #nav-about,
#contact #nav-contact {
  background-position:0% -150px;
  border-width:0;
  }
#home #nav-home a,
#news #nav-news a,
#products #nav-products a,
#about #nav-about a,
#contact #nav-contact a {
  background-position:100% -150px;
  color:#333;
  padding-bottom:5px;
  }

L'exemple 10 présente les effets de l'application d'un id="news" au body et l'exemple 10a montre ce qui arrive quand body utilise id="products".

Notes additionnelles

Têtes de boîtes : Vous avez peut-être sur vos pages des cartouches extensibles qui dessinent une boîte autour d'un titre et de son contenu associé. En assumant que vous utilisez un conteneur (comme un div) pour englober le titre du cartouche et son contenu, cela vous donne déjà les deux éléments pour chaque image de fond (le div et le titre). Dans ce cas, vous préférerez probablement placer l'image la plus étroite à droite, comme dans l'exemple 2. Cela vous donnera un contrôle total sur le point de départ à gauche du titre. Pour donner l'illusion que le cartouche est fait d'un seul bloc, dégradez le bas de chaque image vers la couleur de fond du conteneur.

Pivotements : Si vous pouvez prédire approximativement la hauteur d'un élément d'interface (ou si vous créez une image assez grande pour permettre une expansion verticale), vous pouvez retourner le «passage » sur le côté, en vous servant d'une image pour le haut et d'une autre pour le bas (au lieu de gauche et droite). Rappelez-vous de prendre en compte les cas extrêmes de césures, possibles avec les fenêtres de navigateurs étroites ou les textes agrandis.

Clignotement d'IE : Si vous remarquez un clignotement des images en survolant les onglets dans IE/Win, vérifiez les réglages du cache pour les fichiers Internet temporaires (Outils > Options Internet > onglet Général > bouton Paramètres). Il se pourrait que vous ayez changé le réglage par défaut pour être sûr de voir la version la plus récente à chaque rafraîchissement de page. IE/Win a des difficultés à maintenir les images d'arrière-plan sur les ancres si vous avez choisi "À chaque visite de la page". Le réglage par défaut est "Automatiquement", ce qui permet au navigateur de récupérer instantanément l'image dans le cache, et d'éviter tout clignotement. La plupart des utilisateurs ne changent jamais ce réglage ; les , ils ne connaissent même pas son existence.

Onglets multi-mots : Si le texte de vos onglets contient plus d'un seul mot, ce qui arrive souvent, n'hésitez pas à ajouter une déclaration white-space:nowrap à la règle de l'ancre, empêchant toute césure du texte d'onglets dans certains navigateurs.

Il se pourrait que d'autres problèmes, altérations, et variations de cette technique existent déjà, ou surgissent à terme. Mais nous nous en tiendrons là pour l'instant. Nous espérons avoir déjà comblé quelques lacunes, et dissipé quelques doutes sur l'utilité et la flexibilité des Portes Coulissantes. Faisons mieux, faisons plus.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : Sliding Doors of CSS, Part II
  • Auteur : Douglas Bowman
  • Date de parution : 30 octobre 2003
  • Traduction : Samuel Latchman
  • Date de traduction : janvier 2004
  • Thème : CSS
  • Niveau : Confirmé


Pompage.net - CSS : on reprend tout à zéro !

Pour des sélecteurs CSS raccourcis

Par Harry Roberts

De manière très générale, je pense que plus un site prend de l’ampleur, plus il faut raccourcir les sélecteurs. Je veux dire par là que si vous voulez produire des sites web extensibles, faciles à maintenir, flexibles et au comportement prévisible, alors vous devez être attentif à ce que vos sélecteurs CSS soient aussi gérables que possible pour les développeurs, et donc aussi courts que possible.

Des CSS raccourcis vont servir à beaucoup de choses :

  • augmenter l’efficacité des sélecteurs ;
  • réduire la dépendance à la position dans la page ;
  • augmenter la portabilité ;
  • diminuer les risques de casse des sélecteurs ;
  • réduire la spécificité ;
  • voire autoriser davantage d’erreurs dans le code.
    Cette liste est très vague, je vais donc détailler chacun de ces avantages. Vous verrez qu’il y a beaucoup de croisements entre chacun de ces points (par exemple, le fait de réduire la dépendance vis-à-vis de l’emplacement rend forcément vos sélecteurs plus portables), mais de mon point de vue, ils méritent tous d’être étudiés individuellement.

Augmenter l’efficacité des sélecteurs

J’ai déjà écrit au sujet de l’efficacité des sélecteurs CSS. Dans ce billet, je compte détailler un certain nombre de points plus complexes, donc pour une meilleure compréhension de l’ensemble, je vous recommande de commencer par la lecture de Writing efficient CSS selectors.
Si on met à part certains types de sélecteurs (*{} étant souvent le plus lent, selon la façon dont il est employé ; les ID sont les plus rapides, suivis par les classes ; les descendants sont relativement lents, suivis par les pseudo-sélecteurs), alors on peut dire de façon générale que les sélecteurs les plus courts sont les plus rapides.

On le voit de façon très évidente en comparant ces deux sélecteurs :

html body .entete .nav{}
.nav{}

On voit ici assez clairement que dans le premier exemple, le navigateur doit chercher quatre choses : la classe .nav, puis la classe .entete, puis l’élément body, et enfin l’élément html (car les navigateurs lisent les sélecteurs de droite à gauche).
Dans le second exemple, le navigateur ne cherche qu’une seule chose : la classe .nav. Le navigateur a donc quatre fois moins de travail à faire pour faire fonctionner ce sélecteur. Donc, dès que vous écrivez un sélecteur, essayez de l’élaguer autant que possible. À la place de ul.nav{} (2 points de vérification), écrivez .nav{} (1 seul point). Au lieu de .nav li a{} (3 points), écrivez .nav a{} (2 points).

Il est vrai que la performance des sélecteurs CSS, dans l’ensemble, n’est plus vraiment un point qui doit nous causer énormément de soucis, mais cela ne veut pas dire non plus qu’il faut faire n’importe quoi. J’imagine que pour la plupart d’entre nous, ce n’est pas un drame de perdre 5€ ; et pourtant personne ne glisse volontairement de billets dans la déchiqueteuse... L’efficacité des sélecteurs est un réel problème, donc autant l’améliorer là où vous pouvez le faire très facilement.

Réduire la dépendance vis-à-vis de l’emplacement

Avec des sélecteurs plus courts, vous allez vraisemblablement réduire le nombre de sélecteurs descendants (par ex. .barre_laterale .promo{}) et enfants (par ex. .barre_laterale > .promo{}). En vous débarrassant de ces types de sélecteurs descendants, vous réduisez la nécessité de localiser un élément au sein d’un autre. Reprenons l’exemple .barre_laterale .promo{}...

Avec un sélecteur comme .barre_laterale .promo{} vous ciblez n’importe quel élément promotionnel installé dans un élément marqué par la classe .barre_laterale. Cela signifie qu’il est obligatoire de toujours utiliser un style donné au sein d’un élément donné ; vous vous retrouvez dépendant de l’emplacement.
En remplaçant .barre_laterale .promo{} par quelque chose comme .promo-secondaire{}, vous pouvez maintenant placer l’élément en question partout où vous voulez. Dans la barre latérale, comme précédemment, mais aussi dans le pied de page, dans l’en-tête, ou après un article.
En réduisant les descendants, vous réduisez du même coup la dépendance et vous pouvez gagner en portabilité...

Augmenter la portabilité

Maintenant que vous n’êtes plus contraints par des sélecteurs dépendants de leur emplacement, vous allez voir que vos composants sont beaucoup plus portables. Il devient beaucoup plus simple de déplacer diverses choses, parce que la CSS n’a plus à savoir où loge tel ou tel machin : elle a juste besoin de savoir qu’il existe ! C’est cool !
Une autre manière d’augmenter la portabilité, c’est d’éviter de qualifier les sélecteurs. Un sélecteur qualifié, c’est par exemple ul.nav{}, ou a.bouton{}, ou encore div.contenu{}.

Les sélecteurs qualifiés sont à éviter parce qu’ils réduisent l’efficacité (en obligeant à davantage de points de vérification), mais surtout parce qu’ils vous rattachent de force à des éléments spécifiques. Impossible désormais d’utiliser notre classe .bouton sur un <input> ou sur un <button>, par exemple. Impossible d’appliquer .nav à une liste <ol> pour en faire un fil d’Ariane.

Les sélecteurs ne devraient pas renvoyer à un élément. Votre CSS devrait se moquer éperdument de l’élément auquel vous voulez appliquer un style.
Une autre façon de rendre les sélecteurs plus portables serait... de ne pas s’occuper du tout des éléments. Regardez ceci, par exemple :

/* Styles de base d’un widget */
.widget{}

/* Style amélioré pour le titre d’un widget */
.widget > h2{}

Vous vous retrouvez là avec un sélecteur qui pourrait poser de sérieux problèmes : imaginez que ce <h2> doive devenir un jour un <h3> ? Ou bien imaginez qu’il faille ajouter un autre <h2> enfant de widget mais qui ne soit pas stylé en titre ? Vous venez de vous fabriquer un sélecteur très rigide et pas du tout portable. Ce serait beaucoup mieux d’avoir :

/* Styles de base d’un widget */
.widget{}

/* Style amélioré pour le titre d’un widget */
.widget-titre{}

Vous pouvez maintenant appliquer .widget-titre à n’importe quel élément, un <h4> par exemple, tout en conservant tous les autres <h4> que vous voulez dans le widget, mais sans nécessairement leur appliquer de style de titre. Cool cool !

Diminuer les risques de casse des sélecteurs

Plus un sélecteur est long, plus il nécessite de conditions pour que le navigateur l’applique. Et logiquement, plus il y a d’éléments à vérifier, plus il y a de chances que quelque chose tourne mal. Un sélecteur (certes très exagéré) comme body > div:nth-of-type(2) > article:first-child > p:first-child{} , exemple que je tire de ma présentation Breaking Good Habits, contient pas moins de dix points de vérification : donc dix exigences que le navigateur va devoir vérifier pour savoir si ce sélecteur s’applique.

Il suffit que l’emplacement du div:nth-of-type(2) soit modifié, ou bien que le p:first-child devienne un bloc de citation (blockquote), ou encore que article:first-child ne soit plus enfant de div:nth-of-type(2), bref : il suffit qu’il arrive n’importe quel événement pour que ce sélecteur se retrouve brisé. Si vous remplacez tout cela par une simple classe .intro{} , au pire il n’y aura que cet élément-là qui se brisera, et c’est un risque proche de zéro (il faudrait carrément effacer la classe du HTMLpour en empêcher le fonctionnement).
Des sélecteurs plus courts, c’est statistiquement le meilleur moyen d’empêcher les choses de mal tourner.

Réduire la spécificité

Attention, voilà le gros morceau ! On arrive au cœur de la question...
Des sélecteurs plus longs ont une spécificité plus élevée. La spécificité, c’est un cauchemar : il faut la maintenir à un niveau aussi bas que possible. Vous savez déjà qu’il ne faut surtout pas employer d’ID dans les CSS, mais bien souvent vous ferez tout autant de dégâts si vous employez une chaîne de sélecteurs (enfin, presque).
Un sélecteur comme .widget > h2{} a une spécificité plus élevée (en dehors des autres problèmes déjà évoqués) qu’un sélecteur du genre .widget-titre{}.
.nav li a{} a une spécificité plus élevée que .nav a{} (sans compter que c’est moins efficace). Réduire la longueur du sélecteur, c’est réduire sa spécificité ; et ça, c’est très important. Une spécificité élevée finit par auto-alimenter des conflits de spécificité qu’on ne peut résoudre qu’en créant par la suite des sélecteurs encore plus spécifiques (ou alors en utilisant !important, que la honte s’abatte sur vous). C’est absolument horrible. La façon la plus simple de réduire la spécificité (une fois que vous aurez complètement purgé vos CSS de toute trace d’ID) est d’avoir des sélecteurs raccourcis.

Autoriser davantage d’erreurs dans le code

Voici un exemple très spécifique mais très parlant de la façon dont des sélecteurs courts peuvent autoriser un certain nombre d’erreurs. Je préviens tout de suite qu’on peut avoir deux opinions opposées à ce sujet : soit on dit que cela rend le code beaucoup plus souple et que les problèmes peuvent être traités d’autant plus facilement, soit au contraire on trouve que c’est une approche qui favorise justement l’apparition de problèmes, parce qu’elle est trop permissive. Quoi qu’il en soit, je m’en vais vous raconter une histoire vraie...

Un jour que je travaillais sur un assez gros projet chez Sky, j’ai voulu appliquer mes propres règles et j’ai codé une barre de navigation (verticale) comme ceci :

.nav{ /*styles de la navigation*/ }

/* Nota bene : pas de style pour .nav li puisqu’il s’agit d’une navigation à empilage vertical */

.nav a{ display:block; /*styles supplémentaires */ }

Or, il y avait une erreur dans le CMS qui est passée inaperçue. Voici le code qui était généré :

<ul class="nav">
    <a href="#"></a>
    <a href="#"></a>
    <a href="#"></a>
    <a href="#"></a>
</ul>

Vous voyez le problème ? Aucune <li> ! C’est vrai que ce n’est pas cool du tout, mais comme j’avais employé .nav a{} au lieu de .nav li a{} il n’y a pas eu de souci. Mon code était bien plus tolérant que si j’avais mis une troisième condition. Bien sûr, cela ne rend pas le balisage impeccable pour autant, et c’est vrai que cela laisse passer un balisage de moins bonne qualité que si les sélecteurs avaient été plus complets ; néanmoins chacun peut voir que la CSS a permis à l’ensemble de fonctionner en dépit d’une erreur de balisage. Certes, comme je l’ai déjà dit, on peut m’opposer le contre-argument qui dit qu’un sélecteur plus complet aurait justement repéré l’erreur du CMS illico puisqu’aucun style n’aurait affecté les <a>. Oui, mais ! Quoi qu’on en dise, notre CSS avait assez de souplesse pour tolérer cela. C’est à vous d’en tirer vos propres conclusions, car moi aussi je me suis senti tiraillé entre les deux options, un peu ennuyé que l’erreur n’ait pas été détectée, mais en tout cas c’est là un exemple très spécifique de la façon dont des sélecteurs plus courts peuvent rendre votre code moins sensible aux erreurs.

Le mot de la fin

J’ai dit qu’il s’agissait là d’une règle que j’applique aux sites de taille importante, mais franchement, vous devriez l’appliquer partout. Tout ce dont nous venons de parler intéresse prioritairement les projets d’importance (où l’absence de cette règle se fait sentir douloureusement), mais je vous assure qu’elle vous sera utile sur des projets de toutes tailles. Vraiment.
En conclusion, il est vraiment possible d’améliorer grandement la qualité de notre code : il faut plus de classes et moins de descendants, des sélecteurs courts et portables, des sélecteurs neutres vis-à-vis des éléments, et une approche générale qui consiste à penser à la maintenance et aux modifications à venir au moment de l’écriture des CSS. Les choses peuvent devenir plus efficaces, plus tolérantes, plus souples et plus réutilisables rien qu’en repensant l’usage de l’un des éléments les plus simples et les plus fondamentaux des CSS : les sélecteurs.

Fiche technique

  • Article original : Keep your CSS selectors short
  • Auteur : Harry Roberts
  • Date de parution : mai 2012
  • Traduction : Frédéric Chotard
  • Relecture : Goulven Champenois, Véronique Bouvier
  • Date de traduction : novembre 2013
  • Thème : CSS


Pompage.net - CSS : on reprend tout à zéro !

Quand CSS et Courriel s’embrassent sous le gui

Par Mark Wyner

En tentant de recréer un design sophistiqué dans un courriel HTML à l'aide de CSS, on se heurte souvent à un mur qui peut se présenter soit sous la forme d'inexplicables mutilations par les clients mail, soit sous celle d'un mail sentencieux de la part d'un administrateur de messagerie, statuant que les CSS sont “contre les règles”. Si vous aussi vous en avez assez de vous taper la tête contre les murs et d'utiliser les balises font, cet article est pour vous.

Contrairement à ce que l'on peut penser, vous pouvez créer en toute tranquillité des courriels HTML avec une bonne vieille CSS façonnée à l'ancienne. Oui, vous avez bien lu. Et même si tous les attributs ne seront pas de la partie, la plupart fonctionneront de manière irréprochable avec cette méthode.

D'abord arrive l'amour : pour le meilleur et pour le pire

Entre des articles sur le web design, des conversations entre professionnels, et des retours d'administrateurs de messagerie, j'ai fini par apprendre que certains clients mail massacraient allégrement les CSS en supprimant les styles ou en tronquant les en-têtes. J'ai également réalisé que si je voulais réellement utiliser des CSS dans mes courriels, j'avais tout intérêt à lier la feuille de style plutôt que de l'encapsuler.

Comme je n'avais encore jamais lu d'ouvrage ou rencontré d'administrateur de messagerie autorisant l'usage de mes CSS sans une guerre en règle, je m'en étais remis à la sagesse populaire. Quelle n'a pas été ma surprise quand je me suis attaqué au sujet et que j'ai décidé d'expérimenter !

Puis vient le mariage : la remise en cause

Le seul moyen de trouver une méthode pour utiliser les CSS dans les courriels HTML était de remettre en cause tout ce que je savais, et de casser toutes les “règles”. Une fois affranchi de celles-ci, il devenait possible d'explorer chacune des techniques recelant la moindre petite promesse. Voici comment cela s'est passé :

  1. J'ai tout d'abord conçu un mail lié à une feuille de style et je l'ai expédié via un serveur d'administration connecté à de multiples adresses, webmails, et clients de messagerie. Je n'ai pas réalisé de tests sur tous les clients mail, mais tous les leaders des marchés Mac, PC et Unix ont pu être testés.
  2. Après plusieurs essais, j'ai réussi à introduire des styles encapsulés. Ce qui s'est révélé être mon premier pas vers la réussite. (Dans le cadre d'une utilisation poussée des styles encapsulés, il est important de noter que les versions 6.0 et supérieures d'AOL rejetteront tout mail lié à des feuilles de style externes. Eh oui ! Rejetés, renvoyés en vous claquant la porte virtuelle au nez virtuel)
  3. J'ai ensuite lu les codes source (ce qui relève de l'exploit en ce qui concerne les webmails) pour voir comment mon courriel avait pu déguster.
  4. Enfin, j'ai utilisé mon expertise sur les styles mutilés pour tester les méthodes qui devaient, en théorie, éviter un tel massacre.

Mais quand j'ai vu les codes source, j'ai découvert quelque chose de plus horrible que je ne l'aurais cru. C'était incroyable ! En fait, la plupart du HTML n'en était plus - il n'en restait qu'un bric-à-brac de code et (apparemment) de balises propriétaires.

Enfin l'enfant paraît : mode d'emploi

Chaque client mail a sa propre manière de gérer le balisage, chacun avec ses propres bugs, ses fantaisies, ou ses propres méthodes de prise en charge des feuilles de style. Ce qui suit est la liste des problèmes les plus significatifs et de leurs solutions.

Problème :

L'enveloppe de chaque client basé sur la technologie web repose sur HTML, et il en résulte la présence de deux balises body lors de l'affichage d'un courriel HTML. Certains clients tentent de résoudre le problème en supprimant les deux ocurrences; d'autres y ajoutent un “x,” de sorte que <body> se mue en <xbody>. Dans les deux cas, le style définissant la balise body devient inapplicable.

Solution :

Enveloppez le contenu entier de votre mail dans une balise div et appliquez lui les attributs initialement destinés à body. That's all folks! C'est un remède simple et efficace, faisant uniquement appel à une balise <div> supplémentaire.

Problème :

Certains clients affichent purement et simplement les courriels sans aucun style. J'ai d'abord attribué ceci à la mutilation de mon style, pourtant clairement apparent dans le balisage. J'ai donc passé un temps non négligeable à traquer le coupable, testant une multitude de courriels. Hélas, la solution était en fait juste sous mon nez : les styles n'étaient pas supprimés, mais les points (.) précédant leurs noms, si. En l'occurrence, .DefinitionDeStyle{} se transformait en DefinitionDeStyle{}, provoquant ainsi une définition de style sans aucune portée.

Solution :

J'ai utilisé les sélecteurs de classe, qui assurent que chaque style défini commencera par une lettre plutôt que par un point. Ainsi .DefinitionDeStyle{} peut devenir td.DefinitionDeStyle{} ou div.DefinitionDeStyle{} (le cas échéant). Une solution quelque peu déconcertante, mais qui a le mérite d'être efficace et (une fois de plus) accommodante.

Problème :

Les webmails utilisent leurs propres feuilles de styles, et comme celles-ci précèdent les miennes, l'effet de cascade aboutit à une priorité de mes règles sur celles du webmail. De sorte que mes pseudo-classes et mes définitions d'éléments (tel a:link{} et td{}) altéraient par mégarde le design du webmail lui-même. Fichtre !

Solution :

J'ai paramétré précisément chaque définition. C'est ainsi que a:link{} est devenue à la fois span.DefinitionDeStyle a:link{} et td.Contenu a:link{} pour mettre en forme les liens HTML dans les deux niveaux de l'arbre du document. Cette approche peu orthodoxe alourdit le balisage, mais elle assure que mes styles seront appliqués uniquement aux éléments de mon courriel. Elle établit aussi un respect du travail, pour le designer du webmail comme pour ses utilisateurs. Mais surtout, le code qui en résulte est correct et fonctionne comme prévu.

Problème :

Hotmail : le plus démoniaque de tous. Aucune pitié pour les mails en HTML qui s'appuient sur des CSS. Il ne se contente pas d'éradiquer les styles, mais aussi les balises suivantes des courriels : <head>, <title>, <meta>, et <body>. Dites adieu à votre beau design.

Solution :

Je vous recommande de considérer soigneusement jusqu'où vous voulez vous plier à l'ineptie d'Hotmail, car la méthode suivante va demander du dévouement et de la rigueur. Comme la balise <body> et toutes celles qui précèdent se sont évaporées, la seule option consiste à utiliser les styles CSS en-ligne. Les styles définis en-ligne sont pénibles et peu productifs, et vous préféreriez sans doute ne pas avoir à les utiliser, mais ils fonctionnent tout de même. Si vous prévoyez une utilisation massive d'Hotmail par votre public, vous pouvez vous tourner vers cette méthode. Mais si vous n'avez pas à vous soucier d'Hotmail, sautez donc cette étape et pensez aux choses importantes de la vie, comme manger et dormir.

Remarques

Les attributs

Avant de venir me passer un savon parce que vous avez trouvé un attribut qui échoue en utilisant l'une de ces techniques, gardez à l'esprit le fait que je n'ai pas testé tous les attributs CSS. J'ai testé les attributs les plus courants et ceux que j'utilise fréquemment. Vous découvrirez peut-être que votre attribut favori ne marche guère, et c'est la raison pour laquelle je vous adresse toute ma sympathie, et mes encouragements à tester de nouvelles méthodes.

Clients testés

J'ai testé ces méthodes avec MailApp 1.3.2 (Mac), Squirrel Mail (Mac/Windows), AOL 7.0, 8.0, 9.0 (Mac/Windows), Mozilla Thunderbird 0.5 (Mac/Unix), Yahoo Mail (Mac/Windows), Hotmail (Mac/Windows), et Microsoft Outlook 2001/XP (Windows).

Tenez-moi au courant si ces techniques échouent dans votre configuration. Notez tout de même que les capacités d'Eudora en matière d'HTML sont incroyablement faibles, je l'ai donc exclu définitivement de tout test.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : CSS and Email, Kissing in a Tree
  • Auteur : Mark Wyner
  • Date de parution : 26 mars 2004
  • Traduction : Ismaël Touama
  • Date de traduction : juillet 2004
  • Thème : CSS
  • Niveau : Intermédiaire


Pompage.net - CSS : on reprend tout à zéro !

Quelles mesures CSS, pour quel usage ?

Par Dudley Storey

Confrontés au foisonnement des systèmes de mesure CSS, les développeurs web peuvent avoir du mal à comprendre quelles unités il faut utiliser dans leurs pages, et à quel moment. On peut être tenté de toujours utiliser les mêmes mesures, mais ce choix risque de limiter sérieusement l’aboutissement de vos designs. Je propose ci-dessous une liste de suggestions, mais non pas de règles absolues : libre à vous de vous en écarter si vous le jugez préférable.

Les pixels (px)

À choisir pour : les traits de bordure et les éléments généraux, lorsqu’il s’agit de designs à largeur fixe ; également pour les valeurs des décalages des ombres portées en CSS. À éviter pour les points d’arrêt dans @media car cela casse la mise en page en cas de zoom : mieux vaut employer rem ou em.
À éviter pour : la typographie, sauf s’il s’agit d’établir une taille de police de base dans un « reset CSS » (remise à zéro des styles, NdT).

Les pourcentages (%)

À choisir pour : intégrer des images et des conteneurs à taille variable ; et pour définir la hauteur de la balise body dans certains cas.
À éviter pour : la typographie. (Exception : la taille de police pour un reset CSS).

em et ex

À choisir pour : la typographie, et les éléments qui y sont liés (les marges, par exemple), mais sans perdre de vue que em et ex peuvent être très délicats à employer dans des mises en page complexes. L’unité alternative rem est plus appropriée dans ces cas-là.

Les points et les picas

À choisir pour : les feuilles de style d’impression.
À éviter pour : tout le reste.

rem

À choisir si : vous voulez une alternative plus solide et fiable aux solutions avec em ou ex, et pour les mêmes usages, y compris les points d’arrêt dans les requêtes de médias.
À éviter si : vous devez prendre en charge IE8 et les versions antérieures. Sinon, utilisez cette unité mais prévoyez une solution de repli (en fournissant une alternative dans une unité plus courante avant la valeur en rem) ou encore un « polyfill » (c’est-à-dire un script effectuant le calcul dans les navigateurs ne comprenant pas cette unité, NdT).

Unités relatives à la surface d’affichage (vh et vw)

À choisir pour : la typographie réactive ; et pour des conteneurs réactifs « parfaits ».
Difficile de savoir pour quel usage il faudrait éviter ces unités, car vh et vw sont très récents et encore loin d’avoir été totalement exploités en design web. Attention toutefois à l’absence de prise en charge sous IE8 : prévoyez donc des solutions de repli.

Les pouces (in) et les centimètres (cm)

À choisir dans : les feuilles de style d’impression, et en particulier pour les marges des pages.
À éviter pour : tout le reste.

Les caractères (ch)

À choisir pour : dimensionner et positionner les polices à espacement constant. Attention, le support navigateur est incomplet.

Grille de texte (gd)

De préférence pour : des mises en page expérimentales, car c’est une unité qui n’est prise en charge que par IE10+ au moment où j’écris ces lignes. Des substituts de type « polyfill » commencent néanmoins à apparaître.

Nombres bruts

Bien que presque toutes les propriétés CSS exigent que l’unité de mesure soit indiquée dans la déclaration, pour quelques-unes d’entre elles il est préférable de n’employer que des valeurs d’entiers ou à virgule flottante. En particulier, les propriétés line-height (hauteur de ligne) et border-image (image de bordure) sont plutôt à spécifier à l’aide de nombres bruts.

Fiche technique

  • Article original : Which CSS Measurements To Use When
  • Auteur : Dudley Storey
  • Date de parution : novembre 2013
  • Traduction : Frédéric Chotard
  • Relecture : Goulven Champenois
  • Date de traduction : avril 2014
  • Thème : CSS
  • Niveau : Débutant


Pompage.net - CSS : on reprend tout à zéro !

Sprites CSS : Meurs, découpe d’images, meurs !

Par Dave Shea

A l'époque où les jeux vidéos étaient encore amusants (aux heures de gloire du 8-bits), les graphismes étaient par nécessité beaucoup plus simples. Les arrière-plans et les personnages en 2 dimensions étaient dessinés individuellement, point par point, à la façon du pixel-art aujourd'hui renaissant. Des centaines, et plus tard des milliers de petites images appelées « sprites » formaient les briques de la construction visuelle d'un jeu.

Exemple de sprites

La complexité des jeux augmentant, des techniques furent développées pour gérer cette multitude de sprites tout en conservant la fluidité des jeux. L'une d'entre elles rassembla l'ensemble des ces petites images sur une grille maîtresse, images ensuite récupérées en cas de besoin par un code qui consignait les positions de chaque graphique individuel, et qui les affichait sélectivement à l'écran.

Mais qu'est-ce que tout ceci a à voir avec le web ?

Tout ce qui est ancien trouve un jour ou l'autre un nouveau souffle, et tandis que l'essor des jeux en 3D rendait les grilles de sprites obsolètes, l'émergence simultanée des appareils mobiles, offrant des capacités de jeu en 2D, les a remises en vogue. Avec un peu de mathématiques et beaucoup de CSS, nous pouvons maintenant en reprendre le concept de base pour l'appliquer au monde de la conception graphique sur le web.

Plus précisément, nous allons remplacer le découpage d'images traditionnel (et le Javascript qui lui est inévitablement associé) par une solution à base de CSS. Grâce à la façon dont les CSS fonctionnent, nous pourrons même aller plus loin : en construisant une grille d'images et en imaginant une façon d'en récupérer individuellement chacune des cellules, nous pourrons stocker tous les boutons, les éléments de navigation, etc. dans un seul fichier image, y compris les différents états (initiaux et survolés) associés aux liens.

Comment fonctionnent les sprites CSS ?

En fait, CSS contient tous les outils dont nous avons besoin, moyennant un peu de réflexion créative.

Commençons avec l'image maîtresse elle-même. En divisant le rectangle en quatre parties, vous remarquerez sur cette image que nos images initiales sont disposées en haut, avec leur état survolé :hover correspondant juste en dessous. Il n'y a pas pour l'instant de division claire entre les quatre liens. Imaginez donc que chaque groupe de mots est un lien. (Pour une question de simplicité, nous continuerons tout au long de l'article à nous référer aux images de lien comme étant les images initiales et aux états :hover comme étant les « états survolés ». Cette méthode peut être étendue aux états :active, :focus et :visited, mais nous ne nous y attarderons pas ici.)

Ceux d'entre vous qui sont familiers avec la technique de rollovers de Petr Stanicek (Pixy) voient peut-être déjà où nous voulons aller. Cet article doit beaucoup à l'exemple de Pixy pour la fonction de base sur laquelle nous allons nous reposer.

D'abord, un peu de HTML. Tous les bonnes astuces CSS essaient d'ajouter une couche de visuels sur un bloc de code propre, et cette technique n'y fait pas exception :

<ul id="skyline">
    <li id="panel1b"><a href="/traduction/sprites#1"></a></li>

    <li id="panel2b"><a href="/traduction/sprites#2"></a></li>
    <li id="panel3b"><a href="/traduction/sprites#3"></a></li>
    <li id="panel4b"><a href="/traduction/sprites#4"></a></li>

</ul>

Ce code servira de base pour notre exemple. La mode est aux balisages légers, simples, qui se dégradent élégamment dans les vieux navigateurs et dans ceux dans lesquels les CSS ont été désactivées, ce qui est une bonne tendance pour l'industrie. C'est un idéal vers lequel il est intelligent de se diriger. (Nous ignorerons pour l'instant tout texte dans les liens. Appliquez par la suite votre technique de remplacement favorite pour masquer le texte que vous ajouterez au final.)

Appliquer les CSS

Avec ces blocs de base, il est temps de construire la CSS. Une petite note avant de commencer - à cause d'un petit défaut d'Internet Explorer, nous allons être obligé de placer l'image de l'état survolé par dessus l'image initiale quand nous en aurons besoin, plutôt que de remplacer l'une par l'autre. Visuellement, il n'y a pas de réelle différence tant que nous les positionnons précisément, mais cette méthode évite l'ennuyeux clignotement qui apparaîtrait sinon dans IE.

#skyline {
   width: 400px;
   height: 200px;
   background: url(test-3.jpg);
   margin: 10px auto;
   padding: 0;
   position: relative;
}
#skyline li {
   margin: 0;
   padding: 0;
   list-style: none;
   position: absolute;
   top: 0;
}
#skyline li, #skyline a {
   height: 200px;
   display: block;
}

De façon assez contre-intuitive, nous n'allons pas du tout affecter l'image initiale aux liens, mais plutôt à l'élément <ul>. Vous verrez pourquoi dans un instant.

Le reste de la CSS de l'exemple ci-dessus définit des choses comme les dimensions du bloc #skyline et des items de liste, commence le positionnement de ces derniers, et désactive les puces indésirables.

Nous allons laisser les liens comme des blocs vides et transparents (mais avec malgré tout des dimensions bien précises) pour pouvoir déclencher leur action (c'est-à-dire suivre ledit lien), et nous allons les positionner grâce aux <li> qui les contiennent. Si nous commencions à positionner les liens eux-mêmes en ignorant de fait les <li>, nous trouverions vite des erreurs dans des navigateurs plus anciens, autant donc l'éviter.

Positionner les liens

Les <li> sont positionnées de façon absolue, mais pourquoi ne se trouvent-ils pas en haut de la fenêtre du navigateur ? Une propriété bizarre mais utile des éléments positionnés est que tous les éléments enfants qu'ils contiennent basent leur position absolue, non pas sur les coins de la fenêtre du navigateur, mais sur les coins de l'élément parent positionné le plus proche. Résultat, puisque que nous avons appliqué position:relative sur #skyline, nous sommes capables de positionner en absolu les <li> par rapport au coin supérieur gauche de #skyline lui-même.

#panel1b { left: 0;     width: 95px;  }
#panel2b { left: 96px;  width: 75px;  }
#panel3b { left: 172px; width: 110px; }
#panel4b { left: 283px; width: 117px; }

Ainsi, #panel1 n'est pas horizontalement positionné du tout. #panel2 est positionné à 96px à droite du bord gauche de #skyline, etc. Nous avons attribué aux liens une valeur display:block et la même hauteur qu'aux <li> dans le listing précédent, afin qu'ils remplissent complètement les <li> qui les contiennent, ce qui est exactement ce que nous souhaitons.

À cette étape nous avons une zone réactive basique, sans état :hover. Il est probablement plus simple de voir ce qui se passe en affichant les bordures.

Survols

Dans le passé nous aurions appliqué du Javascript pour changer l'image de l'état survolé. Au lieu de celà, nous avons groupé ces états dans une seule image. Tout ce dont nous avons donc besoin, c'est d'une méthode pour extraire sélectivement chaque état pour le lien approprié.

Si nous appliquons l'image maîtresse à l'état :hover sans aucune valeur additionnelle, nous rendons uniquement le coin supérieur gauche visible - ce n'est pas vraiment ce que nous voulons - plutôt que le morceau correspondant à la zone du lien (c'est ce que nous voulons). Nous avons donc besoin de modifier la position de l'image d'une façon ou d'une autre.

Nous travaillons avec des valeurs connues, en pixels. Un soupçon de mathématiques devrait donc nous permettre de décaler suffisamment cette image d'arrière-plan, tant verticalement qu'horizontalement, de manière à ce que seul le morceau contenant l'état survolé soit affiché.

C'est exactement ce que nous faisons ici :

#panel1b a:hover {
   background: transparent url(test-3.jpg)
               0 -200px no-repeat;
}
#panel2b a:hover {
   background: transparent url(test-3.jpg)
               -96px -200px no-repeat;
}
#panel3b a:hover {
   background: transparent url(test-3.jpg)
               -172px -200px no-repeat;
}
#panel4b a:hover {
   background: transparent url(test-3.jpg)
               -283px -200px no-repeat;
}

D'où sortons-nous ces valeurs ? Voici à quoi elles correspondent : la première valeur représente bien sûr le décalage horizontal (depuis le bord gauche), et la seconde le décalage vertical.

Toutes les valeurs verticales sont les mêmes. Comme l'image maîtresse est haute de 400 pixels et que les états survolés se situent dans la moitié inférieure, nous avons simplement divisé la hauteur par 2. Déplacer tout l'arrière-plan de 200 pixels vers le haut nous oblige à appliquer la valeur comme un nombre négatif. Pensez au bord du haut comme À un point de départ, ou 0. Pour positionner l'image d'arrière-plan 200 pixels au dessus de ce point, il paraît sensé de déplacer le point de départ de -200px.

De la même façon, si le bord gauche de chaque lien est à 0, nous devons décaler horizontalement l'image d'arrière-plan de la largeur de tous les <li> précédant celui avec lequel nous sommes en train de travailler. Le premier lien ne nécessite pas de décalage, puisqu'il n'a aucun pixel à sa gauche. Le second lien nécessite un décalage de la largeur du premier ; le troisième, de la largeur combinée des deux premiers liens ; le dernier, de la somme des largeurs des trois autres liens.

Expliquer le processus est un peu lourd, mais jouer avec les valeurs va rapidement vous montrer comment ce décalage fonctionne. Une fois que le système vous sera familier, celui-ci ne présentera plus aucune difficulté.

Voici ce que ça donne : des rollovers CSS utilisant une seule image, et qui se dégradent en une simple liste non-ordonnée.

Boutons

Il n'y a aucune raison particulière à laisser les liens en contact, côte à côte, comme ils l'étaient dans l'exemple précédent. Les zones réactives peuvent être pratiques dans certains cas, mais que se passe-t-il si nous voulons séparer chaque lien dans son propre bouton isolé ? Nous pourrions ainsi ajouter des bordures et des marges, laisser l'arrière-plan sous-jacent s'afficher à travers, et, de façon générale, les traiter séparément, selon nos besoins.

En fait, les briques de base sont déjà en place. Nous n'avons pas besoin de modifier notre code de façon trop radicale : le changement principal réside dans la création d'une nouvelle image d'arrière-plan qui ne continue pas de lien en lien comme dans le dernier exemple ci-dessus. A partir du moment où l'on ne peut plus compter sur l'élément <ul> pour placer l'image d'arrière-plan originale, nous allons plutôt l'appliquer sur chaque <li>, et la décaler de la même manière que nous décalions l'état survolé dans l'exemple précédent.

Avec une image appropriée et un peu d'espacement entre chaque <li>, nous avons des boutons.

Remarquez que dans cet exemple nous avons ajouté une bordure de 1 pixel, qui contribue bien sûr à la largeur finale du lien. Ceci affecte nos valeurs de décalage, et nous avons compensé en ajoutant 2px aux déplacements de l'arrière-plan aux endroits appropriés.

Les formes irrégulières

Jusqu'à présent nous nous sommes concentrés uniquement sur des formes rectangulaires, qui ne se chevauchent pas. Mais quid des image maps bien plus complexes, que des logiciels comme Fireworks ou ImageReady exportent si facilement ? Détendez-vous, nous avons aussi prévu le cas.

Nous allons commencer de la même façon que pour le premier exemple, en appliquant l'image d'arrière-plan sur l'élément <ul>, en masquant les puces des items de liste, en définissant des largeurs, et ainsi de suite. La grosse différence est l'endroit où nous positionnons les <li>, le but étant d'entourer chaque élément graphique par une boite qui le serre au plus près.

À nouveau, grâce à la capacité de positionner de façon absolue relativement au coin supérieur gauche de l'élément <ul>, nous sommes capable de placer précisément nos liens là où nous les voulons. Tout ce qu'il reste à faire maintenant est de mettre en place les états :hover.

Le plus embêtant dans ce cas est qu'un seul jeu d'images "avant" et "après" ne suffit pas. A cause des objet qui se chevauchent, se reposer sur une seule image survolée afficherait des morceaux survolés des objets entourant le nôtre. En fait, il montrerait exactement les morceaux qui sont à l'intérieur des limites du lien. (Le plus simple est encore de le voir en action.)

Comment éviter cela ? En ajoutant un second état survolé, et en choisissant soigneusement où vont se placer les différents objets. L'image maîtresse dans ce cas a séparé les éléments mauve et bleu sur le premier état survolé, et les verts, les oranges et les jaunes sur le deuxième. Cet arrangement permet à chaque état survolé d'être affiché correctement, sans inclure de morceaux des éléments adjacents. L'illusion est complète.

Avantages et inconvénients

Quelques réflexions pour conclure. Notre nouvelle méthode des sprites CSS a été testée avec succès dans la plupart des navigateurs modernes, l'insigne exception étant Opera 6, qui n'applique pas d'image d'arrière-plan aux états :hover des liens. Pourquoi, nous n'en sommes pas sûrs, mais çela signifie que nos rollovers n'y fonctionnent pas. Les liens fonctionnent toujours, et s'ils ont été étiquetés correctement, le résultat est une zone réactive statique mais utilisable dans Opera 6. Nous y survivrons, surtout qu'Opera 7 est disponible depuis un bout de temps.

L'autre souci est familier à tous ceux qui ont déjà passé un peu de temps sur le remplacement d'images . Dans les rares cas où les utilisateurs ont désactivé les images dans leurs navigateurs mais pas les CSS, un grand vide apparait dans la page, là où nous voulions que nos images soient placées. Les liens sont toujours présents et cliquables, mais rien n'apparaît visuellement. Au moment de la rédaction de cet article, il n'y avait pas de parade connue.

Ensuite il y a la taille du fichier. La tendance habituelle est de supposer qu'une image complète de taille double doit être plus lourde que son équivalent en petites images découpées, car l'aire totale de l'image sera généralement plus grande. Cependant, tous les formats d'images ont une certaine charge opérationnelle (qui explique pourquoi une GIF transparente de 1px sur 1px prend environ 50 octets), et plus vous avez de pièces, plus les charges opérationnelles s'additionnent rapidement. De plus, une image maîtresse de type GIF requiert seulement une table de couleurs, tandis que chaque pièce nécessiterait la sienne. Des tests préliminaires suggèrent une taille totale inférieure pour les sprites CSS, ou, au moins, pas significativement plus importante.

Finalement, n'oublions pas que notre balisage est agréable et propre, avec tous les avantages que cela entraîne. Les listes HTML se dégradent merveilleusement, et un bon mécanisme de remplacement par image laissera le texte des liens accessible aux lecteurs d'écran. Remplacer les graphiques du sprite est simplissime, puisque toutes nos dimensions et nos décalages sont contrôlés par un seul fichier CSS, et que la totalité de l'imagerie est contenue dans une seule image.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : CSS Sprites: Image Slicing's Kiss of Death
  • Auteur : Dave Shea
  • Date de parution : 5 mars 2004
  • Traduction : Steve Frécinaux
  • Date de traduction : avril 2004
  • Thème : CSS
  • Niveau : Intermédiaire


Pompage.net - CSS : on reprend tout à zéro !

Techniques et astuces pratiques pour une mise en page CSS

Par Mark Newhouse

La campagne de mise à jour de navigateurs (Browser Upgrade Initiative) du WaSP), a encouragé de nombreux designers à s'aligner sur les Standards pour leurs pages Web, en utilisant les CSS au lieu de tableaux pour leur mise en page.

"Les tableaux sont morts..."

De nombreux designers web ont suivi l'exemple de Jeffrey Zeldman en publiant des tutoriels pour nous aider à passer le cap du design sans tableaux. Leurs premiers efforts ont visé à créer une ou plusieurs colonnes en utilisant le positionnement CSS au lieu de tableaux, ce qui permet de séparer complètement la structure de la présentation. Ces techniques générales ont été documentées et archivées sur le site d'Eric Costello (glish) ainsi que sur celui de Rob Chandanais (Blue Robot).

D'autres ont suivi leur exemple, comme les Box lessons d'Owen Briggs ou le "hack" de Tantek Çelik, détaillé par Eric Costello et expliqué par Tantek lui-même. Sur le Web, Dotfile et Web Nouveau (un site qui n'existe plus - NDT) font la liste de centaines de sites conçus avec une mise en forme CSS.

"...vivent les tableaux !"

Mais bien que ces excellentes présentations nous permettent de créer une mise en page en utilisant uniquement le positionnement CSS, d'autres questions pratiques se posent, lorsqu'en tant que designers web, nous sommes confrontés à un problème trivial à résoudre avec des tableaux, mais moins évident avec CSS. Une question de cet ordre fut posée sur la mailing-list Webdesign-L, dont le titre était Tables are dead... long live tables.

La question

Supposez que vous vouliez avoir une page avec des images vignettes qui soient liées aux versions normales de ces images - un genre de page plutôt courant sur le Web. Supposez maintenant que chaque image contienne une courte description que l'on désire voir apparaître centrée sous l'image. Enfin, afin d'utiliser au mieux l'espace d'affichage de votre navigateur, vous désirez aligner ces paires d'images/titres en ligne sur l'écran, mais de manière à ce qu'elles se réalignent lorsque que la largeur de la fenêtre du navigateur change (design fluide). Cette dernière spécification nous emmène hors des sentiers battus des tableaux, vers le royaume des CSS...

Un pas après l'autre

Regardons cela pas-à-pas. La première étape consiste à centrer les titres sous les vignettes. Cela est relativement simple : dans votre page HTML vous placez votre image, suivie d'un retour à la ligne (<br />), puis vous placez votre titre dans un paragraphe centré via CSS.

La prochaine étape consistera à aligner ces paire d'images/titres dans la fenêtre du navigateur. Si l'on utilisait des tableaux pour la mise en page, chacune de ces paires serait rangée dans un td. Puisqu'on utilise CSS, nous les mettrons dans des balises div, que nous alignerons horizontalement dans la fenêtre en utilisant un float à gauche dans la feuille de styles.

Voilà à quoi ressemblera la feuille de styles à ce moment :

div.float {
     float: left;
 }

div.float p {
     text-align: center;
  }

Quant au HTML :

<div class="float">
 <img src="image1.gif" width="100" height="100"
 alt="image 1" /><br />
 <p>légende 1</p>
</div>

<div class="float">
 <img src="image2.gif" width="100" height="100"
 alt="image 2" /><br />
 <p>légende 2</p>
</div>

<div class="float">

 <img src="image3.gif" width="100" height="100"
 alt="image 3" /><br />
 <p>légende 3</p>
</div>

Et dans le navigateur :

légende 1

légende 2

légende 3

La prochaine étape ne peut être résolue qu'avec les CSS. Nous voulons que les paires d'images/titres se rangent à la ligne suivante si elles sont trop nombreuses pour tenir toutes dans la fenêtre du navigateur. En fait, ce problème a déjà été réglé par l'utilisation d'un float à gauche sur les div. Si nous dupliquons quelques-unes de ces vignettes, celles-ci se rangeront à la ligne (pour en faire l'expérience, changez la largeur de votre fenêtre de navigateur) :

légende 1

légende 2

légende 3

légende 1

légende 2

légende 3

Maintenant, supposons que vous ayez plus d'une catégorie de vignettes à afficher dans votre page, et que vous désiriez les regrouper visuellement, par un arrière-plan et/ou une bordure. Il suffit alors de les entourer d'une balise div :

div.container {
    background-color: #D7E7F2;
   border: 1px solid #287CB1;
 }

Malheureusement, cela pose un nouveau problème. Quand on utilise float sur un élément avec CSS, il n'occupe plus "d'espace", et du coup l'arrière-plan et la bordure apparaissent au-dessus des images au lieu de les entourer. On doit donc ajouter un contenu différent des div en float dans le div d'encadrement. Par exemple, un div d'espacement :

div.spacer {
     clear: both;
 }

Maintenant le HTML apparaît comme suit (remarquez qu'il y a des div d'espacement au début et à la fin du div d'encadrement) :

<div class="container">
<div class="spacer">
 &nbsp;
</div>

<div class="float">
 <img src="image1.gif" width="100" height="100"
 alt="image 1" /><br />
 <p>légende 1</p>

</div>

<div class="float">
 <img src="image2.gif" width="100" height="100"
 alt="image 2" /><br />
 <p>légende 2</p>
</div>

<div class="float">
 <img src="image3.gif" width="100" height="100"
 alt="image 3" /><br />
 <p>légende 3</p>
</div>

<div class="spacer">
 &nbsp;

</div>

</div>

Ce qui nous donne la présentation suivante:

légende 1

légende 2

légende 3

Basé sur le code de sam marshall.

div imbriqués, tableaux imbriqués, quelle différence ?

Nous avons maintenant tout un tas de div imbriqués. En quoi cela est-il meilleur que des imbrications de tableaux ? Cela vient de la façon dont il était originellement prévu d'utiliser ces balises. Les div impliquent un regroupement logique, ou structuré. Même imbriqués, ils représentent un balisage structuré. Dans notre exemple, nous avons regroupé les vignettes avec leurs titres (premier niveau de structure), puis regroupé ces paires avec d'autres paires similaires (second niveau). Ce genre de regroupement structurel convient parfaitement à l'emploi de balises div.

Par contre, les tableaux impliquent une relation entre les titres de colonne et/ou de ligne, et l'information contenue dans les cellules du tableau. En les utilisant pour la mise en page, on perd la sémantique structurelle d'un tableau. On retourne à une utilisation de HTML comme outil de présentation et non de structuration. Et imbriquer des tableaux dans d'autres ne fait qu'aggraver le problème.

form et fonction

Une autre utilisation fréquente des tableaux en présentation sert à aligner les éléments form avec leur vignette. Bien qu'on puisse défendre l'opinion qu'il s'agit là d'une utilisation appropriée des tableaux, les techniques CSS décrites ci-dessous pourront être utilisées pour d'autres besoins de présentation similaires, comme nous allons le voir.

Une présentation de formulaire typique met les vignettes à gauche en les alignant vers la droite, et les champs à droite en les alignant vers la gauche. Le tout étant centré à la jonction du milieu :

Nom:
Age:
Pointure:
Commentaires:

Basé sur un concept original d'Eric Meyer.

Le formulaire ci-dessus a été créé sans l'aide de tableaux. Encore une fois, nous utilisons float pour générer le positionnement. L'astuce consiste à créer un div qui fonctionne comme une ligne du tableau que nous avons l'habitude d'utiliser. Ensuite il nous suffit de créer deux span : un pour les vignettes et l'autre pour les champs du formulaire. On place l'un en float droit, et l'autre en float gauche, puis on aligne le texte du span de la vignette à droite, et celui du span du champ à gauche.

La feuille de style ressemble à cela :

div.row {
     clear: both;
     padding-top: 10px;
 }

div.row span.label {
     float: left;
     width: 100px;
     text-align: right;
 }

div.row span.formw {
     float: right;
     width: 335px;
     text-align: left;
 }

Les styles ci-dessus définissent également une largeur pour les span. Cette dernière peut être absolue comme dans l'exemple, ou en pourcentages dont la somme serait de 100% ou moins, selon le padding et les bordures (ainsi que la présentation générale utilisée). Dans notre exemple j'ai imbriqué le formulaire dans un autre div afin de lui donner une bordure et un arrière-plan.

Le HTML de l'exemple :

<div style="width: 350px; background-color: #D7E7F2; border: 1px solid #287CB1; padding: 5px;
  margin: 0px auto;">
 <form>
  <div class="row">

   <span class="label">Nom :</span>
   <span class="formw"><input type="text" size="25" /></span>
  </div>
  <div class="row">
   <span class="label">Age :</span>

   <span class="formw"><input type="text" size="25" /></span>
  </div>
  <div class="row">
   <span class="label">Pointure :</span>
   <span class="formw"><input type="text" size="25" /></span>

  </div>
  <div class="row">
   <span class="label">Commentaire :</span>
   <span class="formw">
    <textarea cols="25" rows="8">

    Ecrivez quelquechose...
    </textarea>
   </span>
  </div>
 <div class="spacer">
 &nbsp;
 </div>

 </form>

</div>

Devant et au centre

Vous avez sans doute remarqué que le style du div d'encadrement contenait margin: 0px auto;. Cette ligne doit centrer ce div de 400 pixels dans les navigateurs conformes aux standards. Certains navigateurs, comme IE5.x pour Windows, n'implémentent pas cette fonction, mais par contre centrent (incorrectement) les div dont l'attribut text-align prend la valeur center. Pour centrer un div dans de tels navigateurs, vous pouvez inclure un div avec margin: auto (et text-align: left pour aligner le texte correctement) dans un autre div avec text-align en center. Vous pouvez aussi aller voir le Layout Reservoir de Rob Chandanais pour plus de détails, ainsi que d'autres techniques de centrage.

De part et d'autre

Il existe une autre mise en page similaire (mais inverse) qui s'implémente généralement avec des tableaux. Il s'agit de placer des éléments de part et d'autre de la page, comme par exemple lorsque vous désirez placer un logo en haut à droite de votre page, et des éléments de navigation en haut à gauche :

Home > Products[logo]

Ici nous utiliserons le même div.row que précédemment, mais avec d'autres span que pour aligner les éléments de formulaire avec leurs vignettes. Le span de gauche sera en float à gauche, avec le texte aligné à gauche, et celui de droite en float à droite, avec le texte aligné à droite.

Le CSS :

div.row span.left {
     float: left;
     text-align: left;
     font-weight: bold;
    color: #000;
     width: 49%;
 }

div.row span.right {
     float: right;
     text-align: right;
     font-weight: bold;
     color: #000;
     width: 49%;
 }

Le HTML :

<div style="width: 90%; background-color: #666;
 border: 1px solid #333; padding: 0px; margin: 0px auto;">
 <div class="spacer"></div>
 <div class="row">
  <span class="left">Home > Products</span>

  <span class="right">[logo]</span>
 </div>
 <div class="spacer"></div>
</div>

Aide en CSS

acronym et abbr sont des balises utiles, bien que peu utilisées, qui se servent de l'attribut title pour développer l'acronyme ou l'abbréviation. La plupart des navigateurs ne font pourtant rien pour prévenir vos visiteurs qu'il existe quelque chose sous ces mots qui pourrait les aider à en comprendre le sens. Entre alors en scène CSS.

En effet, vous pouvez dans votre feuille de style définir une bordure inférieure sur ces balises, qui vous permet d'attirer l'attention sur elles. Vous pouvez également utiliser CSS pour modifier l'apparence du curseur en curseur "d'aide" (généralement un point d'interrogation) sur les navigateurs qui implémentent cette spécification. Et vous n'êtes pas limités aux balises HTML. Vous pouvez créer une classe .help et utiliser des span pour donner plus d'informations sur les mots ou phrases qui pourraient laisser vos lecteurs perplexes.

Utilisez ce CSS :

abbr, acronym, .help {
 border-bottom: 1px dotted #333;
 cursor: help;
 }

en conjonction avec l'attribut title ou avec les balises abbr et acronym, afin de créer un effet de souligné différent du soulignement des hyperliens. En modifiant l'apparence du curseur, vous indiquez que ce mot n'est pas cliquable, et l'attribut title développe l'abbréviation ou l'acronyme. J'ai vu cela mis en oeuvre pour la première fois sur le site de Sander Tekelenburg.

Tous en rang !

J'ai appris comment mettre le display d'une liste en inline dans l'ouvrage Cascading Style Sheets de Bos et Lie. Je l'ai vu mis en oeuvre pour la première fois sur le site de Christopher Schmitt BabbleList. Cette technique prend une liste et l'affiche inline, c'est-à-dire horizontalement. Donc au lieu de :

  • Premier élément
  • Deuxième élément
  • Troisième élément

on a :

  • Premier élément
  • Deuxième élément
  • Troisième élément

En ajoutant du padding et un effet de bordure on obtient :

  • Premier élément
  • Deuxième élément
  • Troisième élément

Le CSS :

li.inline {
     display: inline;
     padding-left: 3px;
     padding-right: 7px;
     border-right: 1px dotted #066;
 }

li.last {
     display: inline;
     padding-left: 3px;
     padding-right: 3px;
     border-right: 0px;
 }

Le HTML :

<ul>
 <li class="inline">Premier élément</li>
 <li class="inline">Deuxième élément</li>
 <li class="last">Troisième élément</li>

</ul>

La fin ? Ou le commencement ?

J'espère que le fait d'avoir partagé ces techniques avec vous vous encouragera à utiliser plus fréquemment une mise en page CSS dans vos publications Web, et que vous continuerez à découvrir et à partager avec d'autres de nouvelles techniques.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : Practical CSS Layout Tips, Tricks and Techniques
  • Auteur : Mark Newhouse
  • Date de parution : 2001
  • Traduction : Denis Poisson
  • Date de traduction : septembre 2002
  • Thème : CSS
  • Niveau : Intermédiaire


Pompage.net - CSS : on reprend tout à zéro !

Dernière édition - 21/10/2015

De l’audit de contenu aux idées de design : : Comment un audit de contenu facilite le processus de décision et influence la stratégie de design par Christopher Detzi

Lire l'article.

Concevoir un design sans la couleur par Mark Boulton

Cet article est le premier d’une série publiée sur le blog du designer Mark Boulton. Mark propose ici de démarrer un design sans aucune couleur. Lire l'article.

Écrire du JavaScript véloce et à faible empreinte mémoire par Addy Osmani

Les moteurs JavaScript tels que V8 (Chrome, NodeJs) sont spécifiquement conçus pour une exécution rapide des applications JavaScript les plus complexes. En tant que développeur, si vous êtes soucieux de la consommation de mémoire et des performances, il est important que vous connaissiez les mécanismes mis en œuvre dans les moteurs JavaScript des navigateurs de vos utilisateurs. Lire l'article.

Et des archives…

Travailler avec les icônes SVG par Florens Verschelde

30/08/2016 - Un très bon guide détaillé écrit par Florens Verschelde pour travailler les icônes de vos applications web au format SVG.,Il regorge de bons conseils et d’astuces assez avancées. À mettre entre les mains de tous les designer web. Vers l'article…

Traitement de texte multicanal par Information Architects

30/08/2016 - Avec paysage grandissant de périphériques d’accès et d’applications web, la portabilité des documents reste un problème pour beaucoup. Ce plaidoyer pour le format Markdown, un format texte brut idéal pour la rédaction, revient sur l’importance de se libérer des prisons dorées des formats propriétaires des traitements de texte. Vers l'article…

Encore ailleurs…

© 2001-2019 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! -


Pompage.net - CSS : on reprend tout à zéro !

Domptez vos puces, dressez des listes

Par Mark Newhouse

Dès juillet 1999, je pontifiais à propos des vertus des feuilles de style dans diverses listes de discussion. Certaines choses ne changent pas.

Mais ce qui a changé, c'est la façon dont je réfléchis à la mise en forme CSS et à la structure (X)HTML sous-jacente à laquelle elle est appliquée. Par exemple, la plupart des sites que je visite ont un menu, placé dans une zone de navigation. Ceux-ci sont généralement constitués d'une suite de liens, le plus souvent placés dans des div ou des paragraphes séparés. Structurellement parlant, cependant, ils ne sont qu'une liste de liens, et devraient correspondre à un balisage de ce type.

Bien sûr, la raison pour laquelle nous ne les implémentons pas de cette manière est que nous ne voulons pas d'une puce devant chacun des liens de notre menu. Dans un précédent article, j'ai donné un aperçu des techniques mettant à profit les CSS pour construire une page web. Une de ces techniques consistait à manipuler une liste, afin qu'elle s'affiche horizontalement et non verticalement.

Aujourd'hui, je vais montrer comment utiliser les CSS pour reprendre le contrôle de listes peu maniables au premier abord. Il est temps pour vous de dire à ces listes comment les choses se passent, au lieu de les laisser faire tout et n'importe quoi dans votre page web.

Préparer le terrain

Dans le cadre de cet article, j'utilise des listes non ordonnées. Le même code CSS peut aussi bien être appliqué à des listes ordonnées, le résultat sera similaire. Sauf déclarations supplémentaires, tous les exemples de cet article utilisent le code suivant pour les listes :

<ul>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
    <li>Item 4</li>
    <li>Item 5 - un peu plus long pour avoir plusieurs lignes</li>
</ul>

Chaque liste est simplement placée dans un div différent, et le code CSS définit le comportement de chaque liste en fonction du div où elle se trouve. Chaque div suit une règle de base :

#base {
    border: 1px solid #000;
    margin: 2em;
    width: 10em;
    padding: 5px;
      }

En l'absence de règles de style supplémentaires, la liste est affichée de cette manière dans le div de base :

  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5 - un peu plus long pour avoir plusieurs lignes

Le positionnement

Parfois, l'alinéa par défaut d'une liste est trop grand pour le design sur lequel vous travaillez. Mais pour certains navigateurs, il ne suffit pas de changer la valeur du margin ou du padding de la liste non ordonnée. Pour forcer la liste à se décaler à gauche, vous devez changer à la fois la valeur du margin et du padding. Cela est dû au fait qu'Internet Explorer et Opéra ont opté pour un alinéa basé sur l'attribut margin-left, tandis que Mozilla/Nestcape utilise l'attribut padding. Pour plus d'information sur le sujet, consultez l'article Consistent List Indentation sur DevEdge.

Dans l'exemple suivant, les deux attributs margin-left et padding-left de la liste non ordonnée du div sont mis à zéro :

  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5 - un peu plus long pour avoir plusieurs lignes

Notez que les puces sont situées en-dehors du div. Si le bloc conteneur était le body du document HTML, les puces seraient peut-être affichées en-dehors de la fenêtre du navigateur, c'est-à-dire qu'elles disparaîtraient. Si vous voulez que les puces s'alignent à l'intérieur du div, mais sur son bord gauche, fixez au choix le padding-left ou le margin-left à un em.

  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5 - un peu plus long pour avoir plusieurs lignes

Les puces

Peut-être avez-vous travaillé sur un projet qui nécessitait l'emploi de puces personnalisées. Si c'est le cas, il se peut que vous ayez réalisé cet effet en créant un tableau, avec une colonne contenant les puces GIF, alignées en haut à droite, et une autre colonne avec le contenu, qui devrait être séparé dans les items d'une liste. Avec CSS, il est possible d'utiliser une image en tant que puce. Si le navigateur ne prend pas en charge cette partie de CSS (ou n'affiche pas les images), la puce par défaut sera utilisée (ou bien, vous avez la possibilité de spécifier une autre puce HTML si vous le désirez).

La règle de style ressemble à ceci :

ul {
    list-style-image: url(puce.gif);
   }

Et le navigateur l'affiche ainsi :

  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5 - un peu plus long pour avoir plusieurs lignes

Pour spécifier une puce HTML particulière au cas où le navigateur ne supporte pas cette partie de CSS, ajoutez : list-style-type: disc; à votre règle de style. Selon l'image que vous choisissez, il se peut que celle-ci ne s'aligne pas de la manière que vous souhaiteriez avec les items de la liste. Dans ce cas vous pouvez choisir que l'image soit placée à l'intérieur du bloc que constitue la liste des items (plutôt qu'à l'extérieur du bloc). Ajoutez ceci : list-style-position: inside; à votre règle de style pour effectuer ce changement. Ces trois déclarations peuvent être combinées en une seule déclaration abrégée, comme ceci :

ul {
    list-style: disc url(puce.gif) inside;
   }
qui est équivalent à :
ul {
    list-style-type: disc;
    list-style-image: url(puce.gif);
    list-style-position: inside;
   }

Voici comment cela s'affiche dans la page web :

  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5 - un peu plus long pour avoir plusieurs lignes

Il peut arriver que vous manipuliez une liste mais que vous ne vouliez pas de puces, ou que vous vouliez utiliser une autre caractère à la place. Encore une fois, CSS offre une solution simple. Ajoutez simplement l'attribut list-style: none; à votre règle de style, et forcez les items de la liste à s'afficher avec un alinéa négatif. La règle de style ressemblera à ceci :

ul {
    list-style: none;
    margin-left: 0;
    padding-left: 1em;
    text-indent: -1em;
   }

Le padding ou le margin, l'un des deux au choix, doit être fixé à zéro, et l'autre à 1 em. Selon la puce que vous choisirez, vous devrez modifier cette valeur. La valeur négative du text-indent décale la première ligne vers la gauche, créant un alinéa négatif.

La page HTML contiendra notre liste non ordonnée standard, mais avec un caractère quelconque ou une entité HTML de votre choix en lieu et place des puces précédant le contenu des items. Dans notre cas, nous utiliserons &#187;, le double guillemet droit : ».

  • » Item 1
  • » Item 2
  • » Item 3
  • » Item 4
  • » Item 5 - un peu plus long pour avoir plusieurs lignes

Je dois faire remarquer que Netscape6/7/Mozilla (et les autres navigateurs basés sur le moteur de rendu Gecko) ainsi qu'Opera peuvent générer du contenu automatiquement au moyen du pseudo-élément CSS2 :before. Nous pouvons tirer parti de cela pour générer automatiquement le caractère » (ou tout autre caractère) pour les puces. Cela nous permet de n'avoir que le contenu de la liste non ordonnée. Si vous utilisez Opera ou un navigateur basé sur Gecko, le code CSS suivant aboutira à la même liste que ci-dessus, mais en utilisant la liste non ordonnée standard, sans contenu supplémentaire :

#custom-gen ul li:before {
    content: "\00BB \0020";
   }

La propriété content peut contenir des chaînes de caractères, des URIs et d'autres choses encore, y compris des des caractères spéciaux. Pour utiliser ces caractères, comme », il est nécessaire de les encoder selon leurs équivalents HEX. Pour le double guillemet droit, nous utilisons \00BB (l'autre caractère, \0020, est un espace). Le résultat final (rappelez-vous, le caractère ne sera visible que sous Opera ou Mozilla/Netscape) :

  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5 - un peu plus long pour avoir plusieurs lignes

Des listes vraiment en ligne

Qui a dit qu'une liste se devait d'être alignée verticalement avec des puces accrochées à gauche de chaque item ? Peut-être voulez-vous utiliser la structure d'une liste ordonnée de liens pour obtenir visuellement quelque chose proche d'une barre de navigation verticale dans la page web, ou peut-être voulez-vous que vos liens soient alignés horizontalement en haut de votre page.

Cela ne concerne pas seulement les listes de liens. Parfois, vous pouvez avoir besoin de faire une liste au milieu d'un paragraphe, par exemple pour lister des livres que vous aimeriez lire. Au niveau de la structure, il est logique d'utiliser une liste, mais visuellement parlant, vous ne voulez peut-être pas rompre la continuité du paragraphe. Encore une fois, CSS arrive à la rescousse !

Comme cette liste ne sera pas un élément à elle seule, séparée du reste, je ne vais pas la placer dans le div de base que les précédentes listes ont occupés. Cette fois, le balisage consistera en un paragraphe, suivi de la même liste, suivie d'un autre paragraphe.

Je vous entends protester, « Traître ! Je pensais que vous alliez mettre une liste à l'intérieur d'un paragraphe, non pas entre deux paragraphe. »

À cela, je répondrai : « Eh bien, oui. Mais (X)HTML n'autorise pas l'inclusion d'une liste dans un paragraphe. Cependant, avec l'aide de notre feuille de style, ça en aura tout l'air dans notre page web. »

Voici à quoi ressemblent vos règles de style :

#liste-enligne {
    border: 1px solid #000;
    margin: 2em;
    width: 80%;
    padding: 5px;
    font-family: Verdana, sans-serif;
   }

#liste-enligne p {
    display: inline;
   }

#liste-enligne ul, #liste-enligne li {
    display: inline;
    margin: 0;
    padding: 0;
    color: #339;
    font-weight: bold;
   }

Le balisage consiste en un <div id="liste-enligne">. Ce div contient un paragraphe suivi par notre liste non ordonnée standard, elle-même suivie par un paragraphe. La liste non ordonnée a été modifiée de façon à ce que chaque item se termine par une virgule, le dernier item étant clos par un point et un espace.

Le résultat est visible ci-dessous (la liste apparaît en gras et en bleue) :

Un peu de texte avant la liste. Peut-être s'agit-il de l'histoire d'un homme que sa femme appelle pour qu'il achète quelques trucs sur le chemin de la maison, en revenant du travail. Ça n'a pas vraiment d'importance, nous avons juste besoin d'un texte qui précède la liste :

  • Item 1,
  • Item 2,
  • Item 3,
  • Item 4,
  • Item 5 - un peu plus long pour avoir plusieurs lignes.

Et ensuite, un texte qui suit la liste dans le paragraphe. Une ou deux phrases suffisent pour notre exemple.

Comme dans l'exemple précédent des puces personnalisées, nous pouvons mettre à profit les CSS pour générer automatiquement les virgules qui suivent chaque item de la liste, et le point final. Si vous n'aviez à vous soucier que d'Opera et des navigateurs basés sur Gecko, évidemment. La feuille de style ressemblerait à ceci :

#liste-enligne-gen ul li:after {
    content: ", ";
   }

#liste-enligne-gen ul li.final:after {
    content: ". ";
   }

Nous utilisons ici le pseudo-élément :after pour ajouter les virgules à la fin de chaque item, et un point et un espace après le dernier item avec class="final", comme ceci (rappelez-vous, ce ne sera visible que sous Opera ou Mozilla/Netscape) :

Un peu de texte avant la liste. Peut-être s'agit-il de l'histoire d'un homme que sa femme appelle pour qu'il achète quelques trucs sur le chemin de la maison, en revenant du travail. Ça n'a pas vraiment d'importance, nous avons juste besoin d'un texte qui précède la liste :

  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5 - un peu plus long pour avoir plusieurs lignes

Et ensuite, un texte qui suit la liste dans le paragraphe. Une ou deux phrases suffisent pour notre exemple.

La navigation

Comme je l'ai mentionné précédemment, les menus de liens qui apparaissent sur quasiment tous les sites devraient en toute logique être balisés comme des listes, car c'est ce qu'ils sont. De la même façon, nous ne voulons généralement pas que la mise en forme par défaut de la liste s'applique à ces liens, nous pouvons donc utiliser CSS pour changer leur apparence dans la page. Nous l'avons vu juste avant, il est possible de forcer un affichage horizontal des liens (inline) plutôt que des les obtenir empilés verticalement (le comportement par défaut). Si vous faites ainsi, les puces disparaissent et vous avez alors un grand nombre de possibilités pour séparer chaque item de la liste.

Ces exemples de listes horizontales utilisent tous le même div de base avec le style suivant :

#contenu-h {
    padding: 5px;
    border: 1px solid #000;
    margin-bottom: 25px;
   }

Les deux prochains exemples utilisent la même liste non ordonnée que dans les exemples précédents, à l'exception de la dernière ligne rallongée. Ils utilisent aussi une classe supplémentaire qui met à part un des items de la liste.

Les bordures

Le caractère "pipe" | est souvent utilisé pour différencier les choix. C'est un séparateur classique, et il peut être imité en ajoutant une bordure aux items de la liste :

#pipe ul {
    margin-left: 0;
    padding-left: 0;
    display: inline;
   }

#pipe ul li {
    margin-left: 0;
    padding: 3px 15px;
    border-left: 1px solid #000;
    list-style: none;
    display: inline;
   }

#pipe ul li.premier {
    margin-left: 0;
    border-left: none;
    list-style: none;
    display: inline;
   }

Ici, nous avons ajouté class="premier" au premier item de la liste, de façon à ce qu'il n'ait pas de bordure gauche au final.

  • Item 1
  • Item 2
  • Item 3
  • Item 4

Vous pouvez modifier ces styles pour créer un effet de navigation par onglet :

#onglets ul {
    margin-left: 0;
    padding-left: 0;
    display: inline;
   }

#onglets ul li {
    margin-left: 0;
    margin-bottom: 0;
    padding: 2px 15px 5px;
    border: 1px solid #000;
    list-style: none;
    display: inline;
   }

#onglets ul li.courant {
    border-bottom: 1px solid #ffc;
    list-style: none;
    display: inline;
   }
  • Item 1
  • Item 2
  • Item 3
  • Item 4

Dans cet exemple, l'adjonction de class="courant" à un des items de la liste crée une bordure inférieure de la même couleur que le fond de la page, indiquant que l'onglet se rapporte à la page consultée.

Note : Randal Rust a été le premier à partager cette technique, qui a ensuite été reprise par de nombreuses personnes sur la liste de discussion CSS.

Les fils d'Ariane

Un autre type de liens généralement présentés sous une forme horizontale dans les pages web est ce qu'on appelle les fils d'Ariane (NdT : breadcrumbs en anglais, désigne les miettes de pain du Petit Poucet. Le terme est aussi connu en français sous le nom de "chemin de fer"). Les fils d'Ariane vous indiquent où vous vous situez dans l'arborescence d'un site, en la détaillant de la page d'accueil jusqu'à la section ou la page consultée. Si vous vouliez vraiment avoir un balisage significatif, vous opteriez pour la création d'une série de listes imbriquées, car chaque nouvelle section est une partie de la section qui la précède :

<div id="fil">
<ul>
    <li class="first">Accueil
    <ul>
        <li>&#187; Produits
        <ul>
            <li>&#187; Ordinateurs
            <ul>
                <li>&#187; Logiciels</li>
            </ul></li>
        </ul></li>
    </ul></li>
</ul>
</div>

produit ceci :

  • Accueil
    • » Produits
      • » Ordinateurs
        • » Logiciels

Ajouter les règles suivantes à votre feuille de style :

#fil {
    color: #ccc;
        background-color: #006;
        padding: 3px;
        margin-bottom: 25px;
   }

#fil ul {
    margin-left: 0;
        padding-left: 0;
        display: inline;
        border: none;
   }

#fil ul li {
    margin-left: 0;
        padding-left: 2px;
        border: none;
        list-style: none;
        display: inline;
   }

produit ceci :

  • Accueil
    • » Produits
      • » Ordinateurs
        • » Logiciels

Nous pouvons à nouveau générer le caractère » (ou tout autre caractère que vous voudriez utiliser comme séparateur) avec le pseudo-élément :before, combiné à une règle class="first" pour que le premier item n'en ai pas :

#fil-gen ul li:before {
    content: "\0020 \0020 \0020 \00BB \0020";
    color: #ff9;
   }

#fil-gen ul li.premier:before {
    content: " ";
   }

Et le résultat final :

  • Accueil
    • Produits
      • Ordinateurs
        • Logiciels

Une situation réelle

J'aimerais terminer avec une application en contexte réel de quelques-unes des techniques dont il a été question ici. Nous allons utiliser une liste non ordonnée standard, contenant des liens, pour créer un menu dynamique avec des effets d'états survolés. Pour obtenir ces effets d'états survolés, nous allons confier à la liste la tâche de produire la structure, et les styles des ancres produiront la plupart des effets visuels.

  • Accueil
  • Caméras cachées
  • Caméras CCTV
  • Vols du personnel
  • Conseils utiles
  • F.A.Q
  • À notre sujet
  • Contactez nous

Ce menu est en fait une réponse à une question posée par Michael Efford sur la liste de discussion CSS. Michael avait créé exactement ce menu en utilisant un tableau, des images et JavaScript. Il a demandé sur la liste si cela pouvait être réalisé en CSS. J'ai relevé le défi, et avec l'aide de plusieurs autres membres qui ont fait la chasse aux problèmes spécifiques de quelques navigateurs, nous avons obtenu une feuille de style qui repose sur ce balisage :

<div id="boutton">
<ul>
    <li><a href="/traduction/listes#">Accueil</a></li>
    <li><a href="/traduction/listes#">Caméras cachées</a></li>
    <li><a href="/traduction/listes#">Caméras CCTV</a></li>

    <li><a href="/traduction/listes#">Vols du personnel</a></li>
    <li><a href="/traduction/listes#">Conseils utiles</a></li>
    <li><a href="/traduction/listes#">F.A.Q</a></li>

    <li><a href="/traduction/listes#">À notre sujet</a></li>
    <li><a href="/traduction/listes#">Contactez nous</a></li>
</ul>
</div>

Étudions la feuille de style règle par règle, je vais vous expliquer comment est construite chacune d'entre elles.

#boutton {
    width: 12em;
    border-right: 1px solid #000;
    padding: 0 0 1em 0;
    margin-bottom: 1em;
    font-family: 'Trebuchet MS', 'Lucida Grande',
       Verdana, Lucida, Geneva, Helvetica,
       Arial, sans-serif;
    background-color: #90bade;
    color: #333;
   }

La première règle s'applique au div #boutton. Elle définit l'espace que le menu va occuper, et indique de quelle manière la liste et les liens vont se comporter en son sein. J'ai choisi de faire un menu fluide, basé sur les préférences de taille de polices du navigateur, donc (presque) toutes les mesures sont en em. Largeur du menu comprise. La bordure noire pleine à droite provient du design original de Michael. Le padding-bottom fait se prolonger le div sous le menu pour que vous puissiez voir le fond. Encore une fois, comme sur le design original. Le margin-bottom permet de séparer le div de ce qui le suivra. Les couleurs sont celles du design original.

#boutton ul {
    list-style: none;
    margin:0;
   padding:0;
    border: none;
}

#boutton li {
    border-bottom: 1px solid #90bade;
    margin: 0;
   }

Ensuite, j'ai défini l'allure de la liste. Comme chacun des items devait être un lien, et que l'effet d'état survolé des liens devait être défini dans la feuille de style CSS, j'ai, pour l'essentiel, enlevé toute mise en forme de la liste. J'ai ajouté une bordure d'un pixel de la couleur d'arrière-plan du div #boutton, pour simuler un séparateur, tandis que dans le design original, il s'agissait d'une image.

#boutton li a {
    display: block;
    padding: 5px 5px 5px 0.5em;
    border-left: 10px solid #1958b7;
    border-right: 10px solid #508fc4;
    background-color: #2175bc;
    color: #fff;
    text-decoration: none;
    width:100%;
}

html>body#boutton li a {
    width: auto;
   }

#boutton li a:hover {
    border-left: 10pxsolid #1c64d1;
    border-right: 10px solid #5ba3e0;
    background-color: #2586d7;
    color: #fff;
   }

Enfin, j'ai défini les liens. Le design original comprenait des bordures de 10 pixels de large, à droite et à gauche. Ces bordures, accordées à la couleur d'arrière-plan, changent de couleur si le lien est survolé. C'est relativement facile à restituer en CSSgrâce à la pseudo-classe :hover, donc j'ai ajouté cette règle aux styles des ancres.

Il y a juste une astuce dans cette partie de la feuille de style. Pour que les liens soient actifs sur toute la largeur du div, j'ai opté pour display: block;. Cela fonctionne partout, sauf dans Internet Explorer/Windows. Si vous donnez au bloc une largeur explicite de 100%, alors IE/Windows en tient compte. Mais procéder ainsi crée des problèmes sous IE5/Mac et Netscape/Mozilla. J'ai donc utilisé le sélecteur d'enfant '>'pour redéfinir la taille à auto. Comme IE/Windows ne prend pas en charge les sélecteurs d'enfants, il ignore cette règle. IE5/Mac, Opera et Netscape/Mozilla suivent la règle, et tout le monde est content.

La règle de style pour la pseudo-classe :hover assure le changement de couleur de l'arrière-plan et des bordures lorsque les liens sont survolés.

Les règles de style et le balisage de la liste (environ 1ko) remplacent les quelques 5ko de JavaScript et de tableau, sans compter les 8ko environ d'images pour l'effet de rollover. Le balisage n'en est que plus lisible, plus facile à adapter, car vous n'avez plus besoin de créer de nouvelles images si le nom d'un lien change. Maintenant, vous modifiez juste du texte.

La partie visible de l'iceberg

Croyez-le ou non, mais nous n'avons fait qu'effleurer les possibilités de modifications des listes avec les feuilles de style. Je ne vais pas commencer à affirmer que toutes les techniques présentées ici font parties des règles CSS que vous utiliserez le plus, mais je me prend à espérer qu'elles vous feront réfléchir sur le fait que l'utilisation des CSS peut vous amener à utiliser davantage un balisage structurel.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : CSS Design : Taming Lists
  • Auteur : Mark Newhouse
  • Date de parution : 27 septembre 2002
  • Traduction : Jean-Denis Vauguet
  • Date de traduction : janvier 2005
  • Thème : CSS
  • Niveau : Intermédiaire

À propos de l'auteur

Mark Newhouse crée des sites depuis 1996, et met à profit ses compétences de professeur pour présenter les techniques digitales au plus grand nombre. Auteur et présentateur régulier, il a écrit de nombreux articles techniques pour différents sites web, et se pose comme la force créative derrière le populaire site de ressources CSS, Real World Style.

Articles du même auteur

  • Feuilles de Styles en Cascades, Promesse contre Réalité, et un regard vers le Futur
  • Techniques et astuces pratiques pour une mise en page CSS


Pompage.net - CSS : on reprend tout à zéro !

Une terminologie de la conception web

Par Holly Bergevin et John Gallant

Les nouveaux venus dans le domaine du web design découvrent souvent que leurs prédécesseurs ont laissé dans leur sillage un jargon riche, fait d'expressions codées et autres mots à la mode. Il n'est pas facile de se frayer un passage à travers ce maquis de termes et de définitions, et celui-ci peut s'avérer un sérieux obstacle à la maîtrise des fondamentaux. Cet article va faire la lumière sur ce qui pourrait ressembler à première vue à une véritable langue étrangère.

Balises vs Éléments

Certains auteurs confondent ces deux termes, mais il s'agit de deux choses très différentes. Le mot balise se réfère au segment de code HTML délimité par des chevrons (< et >) et s'écrit (par exemple) comme <html>.

La plupart des balises vont par paires, avec une « balise ouvrante » et une « balise fermante ». L'élément entouré par ces balises est donc décrit entre la balise ouvrante et la balise fermante. Le <html> que nous venons d'écrire est une balise ouvrante, et avec sa balise fermante </html> il délimite l'intégralité de l'élément HTML. Notez la barre oblique juste avant le nom de l'élément dans la balise fermante. C'est elle qui établit le statut de la balise en tant que fermante.

Un petit groupe d'éléments sont appelés « vides », comme <img src="image.jpg" alt="" /> (élément image) et <meta http-equiv="content-Type" content="text/html; charset=iso-8859-1" />, qui est une « méta-balise » fréquemment utilisée. Ces balises sont des entités individuelles qui n'entourent donc aucun « contenu », bien qu'elles puissent « appeler » du vrai contenu dans une page. Les éléments vides comme <img src="image.jpg" alt="" /> comportent une barre oblique précédée d'un espace juste avant le chevron final, mais seulement pour les pages en XHTML ou en XML. Les pages HTML ne sont pas obligées d'avoir cet espace+barre oblique à la fin d'un élément vide.

Donc c'est quoi « l'Élément », alors ?

En termes simples, un élément est tout ce qui apparaît entre une paire de balises ouvrante et fermante. On se fiche du nombre de trucs à l'intérieur, ils font tous partie de l'élément. Ce qui veut dire qu'un ou plusieurs éléments peuvent être dans un autre élément. On appelle ce phénomène « imbrication », et l'élément imbriqué est appelé un « enfant » de l'élément « parent ». On dit que les éléments « parents » « contiennent » ou « entourent » leurs enfants. Ces termes signifient qu'un élément complet, avec ses balises, se trouve entièrement à l'intérieur d'une autre paire de balises, le plaçant donc à l'intérieur de cet élément.

L'apparence à l'écran d'un élément n'a rien à voir avec sa nature. Les styles, les attributs, le type d'un élément peuvent tous affecter son apparence mais n'altèrent pas son contenu réel. De plus, il n'est pas permis d'avoir un élément en partie à l'intérieur d'un autre, et en partie en-dehors. C'est ce qui s'appelle une « imbrication incorrecte ».

Div vs Calques

Une source énorme de confusion a pour origine un composant de Dreamweaver appelé « calques », qui permet aux éléments d'une page d'être placés au-dessus d'autres. Ces calques sont structurés dans le code en tant que « div ». En conséquence, beaucoup croient que les div sont des calques, mais ce n'est pas le cas.

Un div est l'abréviation de division, et c'est un élément créé par le W3C pour servir d' « élément bloc » générique quand il n'est pas souhaitable d'utiliser un des éléments blocs plus anciens, comme <h1> ou <p>. Ceux-là et les autres éléments sémantiques transmettent du sens à leurs contenus, en déclarant à la face du monde « Voici un titre » ou « Voici un paragraphe ». Toutefois, ces vieux éléments sémantiques sont aussi associés à des comportements par défaut. Leurs marges et remplissages sont généralement pré-réglés, de manière variable d'un navigateur à l'autre. D'autres comportements plus obscurs peuvent aussi s'appliquer.

Pour cette raison, il a été jugé sage d'ajouter à HTML un élément bloc tout simple, dépourvu de tout le bagage accompagnant les éléments « traditionnels ». C'est ainsi qu'est né le « div » et avec lui l'élément « span ». Le span sert en gros à envelopper un texte pour y appliquer un style, indépendamment du texte autour de lui. Un span est « en-ligne » comme du texte, au lieu d'être « bloc » comme l'élément div, et suit les mêmes règles de rendu que le texte. Par exemple, si vous voulez appliquer une couleur de fond à une phrase unique au milieu d'un paragraphe, placez une balise span de chaque côté de la phrase, et appliquez votre style à ce span.

Donc, un calque Dreamweaver n'est rien d'autre qu'un div qui a été positionné en absolu, ce qui donne à ce div les mêmes comportements que n'importe quel autre élément « absolu ». Quels sont ces comportements ? Eh bien ils sortent du périmètre de cet article, mais jetez un œil à notre article Flowing and Positioning pour tous les détails. Et non, nous n'allons pas définir « périmètre » !

Classe vs ID

Confus pour beaucoup, ce sujet est vraiment simpliste une fois qu'on l'a compris. Il y en a qui se demandent : « Lequel dois-je utiliser ? L'un est-il meilleur que l'autre ? Hein ?! » Si vous vous reconnaissez dans ces questions, préparez-vous à pousser un délicieux soupir de soulagement.

Une classe est simplement un groupe de styles auquel on a donné un « nom » de classe, pour pouvoir l'associer à un élément. Quand une classe est créée dans la feuille de style, on peut l'appliquer à la balise ouvrante de n'importe quel élément. C'est un peu comme une baguette magique que vous pouvez pointer vers un élément en disant « Toi ! Obéis à ces styles ! » Comme toutes les baguettes magiques, vous pouvez la pointer encore et encore, stylant des éléments à gogo. Boum, boum, boum ! Allez-y, stylez votre page jusqu'aux extrêmes, si vous voulez. Le pouvoir de la classe est tellement grand qu'on ne peut plus s'en passer !

Tout ça est bel et bien bon, jusqu'à ce que débarque ce truc, là, ID. Il a l'air de faire la même chose que les classes, alors quelle est la différence ? En fait, la seule vraie différence est qu'ID doit être utilisé seulement une fois par page. Pourquoi est-ce nécessaire ? À cause d'un truc appelé le « DOM », ou « document object model ». Il est utilisé principalement par des scripts pour contrôler dynamiquement les éléments d'une page, et ces scripts sont très pointilleux, en particulier sur « l'identité » des éléments. Vous saisissez ? Quand on applique un ID, on attribue à un élément non seulement des styles, mais aussi une identité précise. Si cet IDIDest utilisé sur plus d'un élément, le DOM ne saura pas lequel vous voulez contrôler, provoquant une erreur de script.

Dans le « monde réel », les navigateurs vous permettront d'utiliser un ID plus d'une fois, généralement sans problème d'affichage, mais seulement si aucun script n'est utilisé. Il vaut donc mieux prendre les bonnes habitudes tout de suite. De cette manière vous ne serez pas « surpris » plus tard. Vous n'avez sans doute pas besoin qu'on vous explique ce mot-là.

Attributs vs Propriétés

Attributs et propriétés sont souvent confondus, mais ils n'ont rien d'identique. Un attribut est placé directement dans une balise HTML ouvrante, et affecte le contenu de l'élément que cette balise délimite. Un bon exemple serait <table bgcolor="#c0c0c0" width="300">. bgcolor et width sont tous les deux des attributs de ce tableau. La syntaxe d'un attribut comprend toujours le nom de l'attribut, suivi d'un signe « égal », et de la valeur de l'attribut. Les guillemets autour de la valeur (comme dans l'exemple précédent) sont optionnels pour des pages écrites avec un doctype HTML, mais obligatoires pour des pages XHTML et XML.

Les propriétés CSS sont (généralement) utilisées dans une feuille de style. Elles ont aussi des valeurs qui définissent l'apparence d'un élément. Certaines propriétés sont similaires aux attributs, par exemple {width : 300px ;} mais la plupart peuvent avoir beaucoup plus de valeurs possibles que n'importe quel attribut. Remarquez la différence de syntaxe pour la propriété width et sa valeur, avec l'ajout obligatoire à cette dernière d'une unité de longueur. L'attribut bgcolor est remplacé en CSS par la propriété background-color. Cette propriété utilise des valeurs similaires à celles disponibles pour l'attribut, ainsi gcolor="#c0c0c0" devient {background-color: #c0c0c0;} dans une feuille de style.

clear="all" est une paire attribut/valeur de HTML, alors que {clear: both;} est la paire propriété/valeur équivalente en CSS. Beaucoup de gens habitués à l'attribut HTML clear vont écrire {clear: all;} dans leur règle CSS au lieu d'employer la syntaxe correcte {clear: both;}. Malheureusement, il est peu probable que {clear: all;} fonctionne, parce que la valeur d'attribut incorrecte all est utilisée au lieu de la valeur de propriété both. Bref, ces deux systèmes comportent de nombreuses différences, tout comme leur syntaxe.

Le W3C a « déclassé » certains attributs HTML , c'est à dire qu'ils devraient être évités au profit de leurs équivalents CSS. align est l'un de ces attributs, tout comme bgcolor d'ailleurs. Cela dit, ils passeront la validation dans des pages au doctype non strict, et peuvent donc être utilisés si nécessaire. De nombreux autres attributs comme href et src ne sont pas près de nous quitter.

L'attribut Style

Une source de confusion possible est la syntaxe des styles CSS « en-ligne ». Ces styles sont contenus dans la balise ouvrante d'un élément, affectant cet élément et lui seul. Il s'agit pourtant toujours de CSS. Comme seuls les attributs sont autorisés dans une balise ouvrante, un nouvel attribut a été créé pour gérer le problème. C'est l'attribut style.

L'attribut style est utilisé pour appliquer des styles à base de CSS directement à l'intérieur de la balise ouvrante d'un élément, et ressemble à ceci : style="width: 300px; background-color: #c0c0c0;". C'est comme une mini-feuille de style complète, nichée dans une balise via l'attribut style.

Notez que l'attribut style suit la même syntaxe que les autres attributs, sauf que sa valeur consiste en une ou plusieurs propriétés CSS suivies de leurs valeurs respectives. L'attribut style exige aussi l'application de guillemets autour des paires propriété/valeur qu'il contient. Pour nous, l'attribut style est pratique pour des tests de style rapides, et aussi pour ajouter des styles à des articles comme celui que vous lisez en ce moment. Ils complètent une feuille de style qui ne peut pas être modifiée par les auteurs. Exemple :

~ Qui a volé l'orangedu marchand ? ~

Feuilles de styles externes, intégrées, et en-ligne

À la différence des attributs HTML qui doivent résider dans les limites d'une balise ouvrante, les styles CSS se présentent sous la forme de « feuilles de styles » ou de listes de règles de styles. Ces feuilles de styles peuvent être appelées depuis un fichier externe (aussi appelé fichier distant), intégrées dans l'élément head d'un document, voire balancées directement dans la balise ouvrante d'un élément en tant que style en-ligne. Toutes ces feuilles de style sont appliquées à une page, mais les différences entre elles peuvent désorienter les non-avertis, et impacter leur ordre dans la « cascade ».

Les feuilles de styles externes sont appelées depuis le head d'un document à l'aide de l'élément <link>, ou de l'élément <style>qui importe (avec @import) la feuille de style. Des feuilles de styles distantes additionnelles peuvent être importées depuis une feuille de styles externe, toujours en utilisant @import dans cette dernière.

Les feuilles de styles intégrées sont les règles contenues à l'intérieur de l'élément <style></style> qui se place dans le head d'une page. Typiquement, si une page contient des styles intégrés, on ne trouvera qu'un élément <style>, mais head peut en contenir plusieurs. Les styles en-ligne, décrits précédemment, sont ceux appliqués à un élément à l'aide de l'attribut style.

Il n'est pas permis d'avoir deux attributs conflictuels au sein d'une même balise. Par exemple, utiliser align="left" et align="right" dans la même balise serait idiot, et de fait un seul des deux serait appliqué. Vous serez peut-être surpris d'apprendre que c'est le premier attribut qui est pris en compte, pas le second. Mais comme les styles CSS sont souvent appelés depuis plus d'un endroit externe au document HTML, par plusieurs pages différentes, et qu'ils existent aussi dans le document source, il est plutôt difficile de prévoir les conflits. Le système de cascade de CSS a été créé pour prendre en charge ce type de problèmes quand ils surgissent. Étudiez Understanding the Cascade pour plus de détails à ce sujet.

XHTML1.0 vs HTML4.01

D'abord un peu d'histoire. Dans les années 1980, le SGML (Standard Generalized Markup Language) fut développé pour décrire les langages structurels en général. Le SGML est suffisamment flexible et complexe pour gérer presque tous les cas de figure. Alors que Tim Berners-Lee travaillait à installer un intranet pour les scientifiques du CERN à Genève, il développa un sous-ensemble simplifié de SGML qui devint HTML (Hyper Text Markup Language). HTML introduisit aussi la nouveauté de l'« hypertexte », qui est le « lien » que nous connaissons aujourd'hui.

Ce langage, HTML, avec sa capacité de faire des liens, devint vite populaire, évoluant dans un court laps de temps vers l'Internet que nous aimons tous. De nombreux nouveaux éléments furent ajoutés, ainsi que le support du multimédia, entraînant des problèmes d'interopérabilité des documents entre différentes plate-formes. Il devint clair que HTML en tant que tel ne pourrait pas constituer une norme à long terme, et XML fut développé dans le but de conserver la plupart des fonctions enviables de SGML sans la complexité qui rendait la vie si difficile aux programmeurs et aux créateurs.

L'un des grand attraits de XML est que les navigateurs basés sur lui seul sont beaucoup plus simples, une qualité hautement désirable pour les appareils portables et consorts. Une autre de ses qualités est qu'il fonctionne bien couplé à des choses comme MathML et Scalable Vector Graphics (SVG). MathML est un langage conçu pour afficher des formules mathématiques exactement comme elles apparaissent sur le papier, et SVG est une méthode permettant des images nettes à n'importe quelle échelle, ainsi qu'un contrôle dynamique de l'image elle-même.

C'est super, mais XHTML dans tout ça ?

L'idée derrière XHTML1.0 est de créer une version de HTML4.01 qui soit en fait du XML ressemblant à HTML. XHTML1.0 doit normalement être servi différemment des pages en HTML4.01, à l'aide du type MIME "application/xhtml+xml" au lieu de l'habituel "text/html". Cela dotera la page des mêmes avantages que les technologies avancées disponibles pour les pages XML, et dénoncera les erreurs présentes avant publication. XML doit être valide, et dans le cas contraire les agents utilisateurs ne sont pas supposés l'afficher.

Néanmoins, la plupart des pages affirmant être du XHTML1.0 sont toujours servies comme du "text/html". Quand cela se produit, la page XHTML est traitée exactement comme une page HTML, et tout code invalide sera considéré avec la tolérance coutumière des agents utilisateurs (les navigateurs) depuis des années. Donc, en fait, il n'y a généralement aucun avantage à écrire des pages en XHTML1.0, à moins d'être prêt à faire en sorte que le serveur les présente comme "application/xhtml+xml".

Notez quand même que si vous faites cela (servir la page en "application/xhtml+xml") et que les règles strictes de XML ne sont pas suivies, il se produira des erreurs. XML n'est pas tenu de tolérer les erreurs comme HTML, ce qui explique pourquoi une application XML peut être tellement plus simple et abordable (et nous nous mordons la langue pour ne pas mentionner un certain navigateur populaire qui ne comprend pas le type MIME application/xhtml+xml...)

La signification de tout cela pour le codeur web moyen qui ne veut qu'une page traditionnelle, c'est qu'il n'y a aucun intérêt à écrire en XHTML1.0. En fait, utiliser un doctype XHTML1.0 sans le servir comme "application/xhtml+xml" pourrait causer des problèmes dans le futur. En gros, si vous n'êtes pas familiers avec l'essentiel de cette discussion, vous faites probablement partie de ceux qui n'ont pas besoin de s'embêter avec XHTML pour l'instant. Vous pouvez continuer à écrire du HTML et à utiliser des doctypes HTML4.01 valides. D'accord, c'est cool d'avoir un bouton XHTML1.0 valide sur votre page, mais vous savez maintenant qu'il faut un peu plus qu'un code nettoyé et un doctype différent pour vraiment faire du XHTML correct.

Note : les trois doctypes XHTML1.0 (strict, transitional, et frameset) peuvent être servis comme "text/html". Par contre il existe un autre doctype XHTML, XHTML1.1, qui doit être servi comme "application/xhtml+xml".

Mais quelles sont les différences entre HTML4.01 et XHTML1.0 ?

L'essentiel de la différence entre XHTML1.0 et HTML4.01 réside simplement dans une rigueur accrue des règles de balisage. Pour les curieux, voici les pré-requis de XHTML1.0 qu'on ne trouve pas dans HTML4.01 :

  • Les documents doivent être bien formés
    « Bien formé » veut dire que tous les éléments doivent posséder des balises fermantes ou être écrits de façon spéciale, et qu'ils doivent être correctement imbriqués. Les éléments comme <br> qui n'ont pas de balise fermante doivent être écrits <br />. La pratique courante qui consiste à omettre les balises fermantes des paragraphes et des items de liste est à bannir. Quant à l'imbrication, si vous avez un <em> ouvrant puis une balise <small>, la balise </small> doit apparaître avant la balise </em>. Les éléments ne peuvent pas se « chevaucher », mais doivent s'imbriquer les uns dans les autres.
  • Les noms d'éléments et d'attributs doivent être en bas de casse
    Les documents XHTML doivent utiliser les bas de casse pour tous les noms d'éléments et d'attribut HTML. XML et XHTML sont sensibles à la casse, à l'inverse de HTML qui se fiche de savoir si vous écrivez <fOrM> ou AliGN=cENTer. C'est aussi valable pour les « attributs » JavaScript comme onMouseOver, lequel doit être écrit onmouseover.
  • Les valeurs d'attribut doivent toujours être entre guillemets
    Toute valeur d'attribut doit être entre guillemets, même celles composées de chiffres. Les guillemets peuvent être simples ou doubles. <td rowspan=3> est donc interdit, et <td rowspan="3"> est correct.
  • Les attributs raccourcis sont interdits
    En HTML, certains attributs sont juste des mots uniques sans signe « égal » ou valeur. En XML et en XHTML, ces attributs doivent suivre la nomenclature standard, l'attribut raccourci de règle horizontale "noshade" devient donc <hr noshade="noshade">.
  • Exit "name", bonjour "id"
    Les éléments a, applet, form, frame, iframe, img, et map, peuvent utiliser l'attribut "name" en HTML, mais en XML il doivent le remplacer par un identifiant "id". Dans le cas de XHTML1.0, bien que l'attribut name ait été déclassé et soit appelé à disparaître, il peut être utilisé pour une « compatibilité descendante » avec HTML.
  • Les valeurs textuelles des attributs doivent être en bas de casse
    Plusieurs attributs comme <input> possèdent des attributs comme "type" qui ont un ensemble de valeurs possibles sous la forme de texte et non de chiffres. Dans ce cas les valeurs doivent être en bas de casse. type="CHECKBOX" est donc incorrect, et doit être tapé type="checkbox".
  • Les références aux entités hexadécimales doivent être en bas de casse
    Les « entités » hexadécimales peuvent servir à placer des signes qu'on ne trouve pas sur un clavier standard. Ces entités doivent toutes être en bas de casse. HTML permet au premier caractère de l'entité d'être en majuscules.

La liste ci-dessus n'est pas exhaustive, mais elle devrait vous donner une bonne idée des différences essentielles entre XHTML1.0 et HTML 4.01. Pour plus d'informationsur le sujet, voyez les articles et spécifications suivantes :

  • Passer du HTML au XHTML
  • la spécification de XHTML 1.0

« Positionné »

Position est une propriété CSSquis'applique à tous les éléments, à l'exception du contenu généré (en CSS 2, la propriété content utilisée en conjonction avec les pseudo-éléments :before et :after,ou les éléments dont la propriété display est établie à list-item, sont les principales méthodes pour générer du contenu).

Les valeurs possibles de la propriété position sont :

  • static (valeur par défaut) ;
  • relative ;
  • absolute ;
  • fixed ;
  • inherit.

Bien que n'importe quel élément puisse effectivement être positionné, on ne parle généralement d'un élément positionné que quand sa propriété position a été réglée à autre chose que static, d'où la confusion à propos du terme « positionné ». Toutefois, en l'absence de propriété position définie, la position d'un élément est static par défaut, ce qui correspond à son flux normal. Cela veut dire qu'un navigateur affichera l'élément en suivant les règles normales de l'affichage écran, en basant la position de l'élément sur son ordre d'apparition dans le code source, de haut en bas, et sur les autres règles gouvernant l'affichage de contenu bloc et en-ligne.

Savoir si un élément a une valeur de position différente de static est important, parce que seuls les éléments en {position: relative;}, {position: absolute;}, ou {position: fixed;} peuvent servir « d'origine» ou de « bloc conteneur » à des éléments « enfants » positionnés en absolu. Les éléments blocs comme <div> ou <li>, et les éléments en-ligne comme <span> ou <strong> peuvent tous servir de blocs conteneurs à des éléments positionnés en absolu. Cela dit, les éléments en-ligne ne peuvent contenir que d'autres éléments en-ligne, pas des éléments blocs. Note : même quand un élément a été positionné, il peut contenir des éléments de « flux normal », c'est à dire qui n'ont pas de propriété position explicitement définie, et donc sont statiques par défaut.

L'utilisation d'éléments avec {position: relative;} ou {position: absolute;} comme conteneurs d'autres éléments positionnés en absolu fonctionne bien, mais {position: fixed;} n'est malheureusement pas pris en charge par IE/Windows (en clair, ça ne marche pas). IE/Win traite un élément ayant {position: fixed;} comme s'il avait {position: static;}, et le laisse dans le flux normal de la page. Dans IE5/Mac, les liens à l'intérieur d'éléments ne fournissent aucun indicateur visuel sur leur état, à moins de cliquer ou de tabuler sur eux. En d'autres termes, le curseur ne se modifie pas pour indiquer que la souris survole un lien. Quelle plaie !

On pourrait se demander pourquoi static fait partie des valeurs de la propriété position, puisque les éléments sans valeur explicite appliquent static par défaut. {position: static;} peut être employé pour transformer un élément ayant une « position » non statique en élément statique. Çela se fait soit en redéfinissant la valeur depuis une autre feuille de style (par exemple une feuille de style d'impression), soit en utilisant un script pour altérer la valeur de position. Retenez juste que static n'est pas considéré comme "positionné", même si c'est une valeur de la propriété position. Oui, c'est un peu bête, mais c'est comme ça.

Dreamweaver peut créer des éléments appelés « calques » (layers en anglais), qui sont en fait des éléments <div> de niveau bloc déclarés en {position : absolute}. Cependant, le terme « calque » n'est utilisé ni dans la spécification de HTML4.01, ni dans celle de CSS 2. De fait, on parle de « présentation par couches » (layered presentation) dans le contexte de la propriété z-index, et pas de la propriété position. Pour plus d'informations sur le positionnement en général, voyez notre article Flowing and Positioning.

Par définition, les propriétés de position ne sont pas héritées par les éléments enfants. Par exemple, l'élément enfant d'un <div> positionné en absolu n'héritera pas du {position : absolute} de son parent. Toutefois, en établissant la valeur de la propriété position à inherit ({position : inherit}), la propriété position d'un élément donné prend la même valeur calculée que celle de son parent.

Au fait, on entend parfois le terme « CSS-P » pour désigner le positionnement CSS (en anglais surtout, mais l'expression peut surgir au détour d'une conversation française - NDT). Ce terme n'a rien de différent, de spécial ou d'officiel, c'est juste une façon de se référer au positionnement en général.

« Conteneur »

Habituellement, quand les gens parlent de « conteneur », ils se réfèrent à un élément bloc qui contient un ou plusieurs éléments enfants entre ses balises. Étant donné que n'importe quel élément bloc comme <div>, <p>, ou <ul> par exemple, peut être le parent d'autres éléments, il est plus facile d'employer « conteneur » comme mot générique. Le W3C appelle ces conteneurs des blocs conteneurs.

Les conteneurs sont fréquemment mentionnés dans le contexte d'éléments positionnés en absolu. Les éléments positionnés en absolu (ou « éléments absolus ») calculent leur origine, c'est-à-dire le point à partir duquel ils sont positionnés, de plusieurs manières.

Comme il a été mentionné précédemment dans cet article, les éléments absolus, en relatif ou en fixe, peuvent servir de conteneurs à des éléments enfants positionnés en absolu. Si un conteneur parent n'est pas positionné (c'est à dire qu'il est dans le flux normal), l'élément enfant absolu ignorera son parent direct non positionné et cherchera plus loin un parent de ce parent qui est positionné. Si ce parent extérieur est positionné, c'est lui qui devient le conteneur origine pour l'élément enfant absolu. Dans ce cas, le parent intermédiaire non positionné ne joue plus aucun rôle dans le positionnement.

Si le parent extérieur n'est pas non plus positionné, l'élément enfant absolu continue sa recherche généalogique en quête d'un parent positionné, jusqu'à ce qu'il soit à court de parents. À ce moment, l'élément racine HTML est utilisé comme origine, ou bloc conteneur initial, par défaut.

Par contraste, les éléments qui ont {position : fixed;} utilisent toujours la zone d'affichage du navigateur comme origine, sans s'occuper du positionnement de leurs parents.

On dit souvent que les éléments flottants sont « retirés du flux », mais ce n'est pas tout à fait correct. Il est vrai qu'un flottant va s'étendre au-dessus du contenu qui le suit (un peu comme les éléments positionnés en absolu), mais le coin supérieur gauche de l'élément flottant restera placé exactement au même endroit où irait une boîte non flottante. Donc, tout en n'étant pas « dans le flux » comme des éléments statiques, ils sont contenus à l'intérieur de leur parent tout comme les éléments dans le flux. Le parent n'a pas à être positionné pour contenir un flottant, à l'inverse du cas d'un élément enfant positionné en absolu.

« Hack CSS »

Le terme « hack » est largement utilisé dans les différentes branches de l'informatique, et comporte certaines nuances selon le contexte, mais globalement il signifie coder d'une manière non orthodoxe dans le but d'obtenir un certain résultat. C'est aussi le sens du terme « hack CSS ». La raison d'être d'un hack CSS est presque toujours de faire en sorte qu'un navigateur obéisse à une règle qu'un autre ignore, dans le but d'avoir dans les deux cas un affichage de page web identique.

Si tous les navigateurs se comportaient de manière similaire, nous n'aurions pas besoin des hacks. Malheureusement, c'est loin d'être le cas. Les "zones floues" dans les spécifications du W3C, les bugs de programmation, voire l'incapacité à adhérer à des comportement standards pourtant acceptés, contribuent tous aux difficultés que rencontrent les codeurs CSS. Tout cela en plus de devoir apprendre CSS ! Pourquoi tant de haine...

Il y a quelques années, les navigateurs ne brillaient pas par leur capacité à bien gérer CSS, mais depuis 2001 la situation s'est radicalement améliorée. Les navigateurs basés sur Gecko (Mozilla, Camino, Netscape7, Firefox) servent maintenant d'étalon pour les autres. Parmi les autres navigateurs actuellement disponibles, citons Opera 7 (sorti en janvier 2003) et Safari (Mac OS X).

Malheureusement, Internet Explorer pour Windows s'est fait distancer. Entre 1995 et 1998, Microsoft a lancé les versions 1 à 5, et en 2001 a sorti IE6. Au moment où nous écrivons (octobre 2004), le support de CSS n'a connu aucune amélioration. De fait, très peu de progrès ont été réalisés par IE/Win en CSS depuis la version 5, il y a 6 ans.

Hack ou pas hack

Certains veulent se montrer irréprochables et codent strictement aux normes de CSS, quelles qu'en soient les conséquences. C'est une noble attitude. Toutefois, comme la plupart des "problèmes" restants se produisent dans Internet Explorer pour Windows, une stricte conformance aux normes sur un site commercial pourrait occasionner des pages "cassées" dans ce navigateur.

À l'autre extrême on trouve ceux qui ne codent que pour IE/Win, ignorant de façon innocente ou délibérée les navigateurs autres que ce "King-Kong" qu'est Explorer. Cette méthode a l'avantage de rendre la mise en page bien plus simple, mais avec le risque potentiel de perdre un certain nombre de visiteurs. Pour toute entreprise avec un volume de ventes internet élevé, même 5% de transactions perdues est un chiffre sérieux. De plus, si vous comptez toucher des professionnels avertis des choses du web, sachez qu'un nombre disproportionné d'entre eux utilise des navigateurs conformes aux standards.

Le doigt dans l'engrenage

Habituellement, quand de nouveaux codeurs commencent à apprendre CSS, ils regardent le résultat de leurs efforts dans IE/Win, ce navigateur étant installé sur la plupart des ordinateurs. Étant novices en CSS, ils expérimentent jusqu'à trouver un code qui rend bien sous IE. Mais sans le savoir ils se forment à utiliser du code non standard pour y arriver. Puis, quand ils entendent parler d'autres navigateurs et téléchargent l'un ou l'autre, ils sont choqués de voir leurs belles créations mutilées. Naturellement, ils blâment ces navigateurs, convaincus de leur culpabilité, alors que la faute revient en fait à leur IE bien-aimé. Quand un patron leur dit qu'il doivent « faire marcher le site » dans tous les navigateurs modernes, ils tentent frénétiquement de corriger ces navigateurs alternatifs, sans savoir que IE est la source du problème.

Des légions de débutants tombent inutilement dans ce piège. Le moyen le plus simple est de lancer un Gecko ou un autre navigateur respecteux des standards, de coder la page pour qu'elle s'y affiche bien, et ensuite d'appliquer des hacks pour IE/Win, en corrigeant tous les problèmes. Oui c'est embêtant, mais c'est bien plus facile que de travailler dans l'autre sens.

IE/Win est tellement important que les auteurs de pages sont forcés de le chouchouter en prenant garde à ses nombreuses failles. Cela ne veut pas dire que IE est le seul navigateur buggé, oh non. Tous les navigateurs ont des bugs, mais aucun ne s'approche seulement du nombre ou de la diversité qu'on trouve dans IE/Win. Il faut remonter jusqu'à Netscape Navigator 4 pour pour constater des écarts de conduite dépassant ceux de IE.

Les codeurs qui préfèrent se passer de hacks, s'ils veulent espérer y parvenir, sont obligés de bien connaître la plupart des problèmes de IE, mais la plupart n'ont pas cette connaissance. Connaître les détails pervers du fonctionnement interne de IE n'est parfois même pas suffisant, parce que sans hack pour résoudre le problème, il devient nécessaire de limiter sévèrement la complexité de la maquette. Cela rend de nombreux designs irréalisables. Frustrant, pour ne pas dire plus.

Le bon, le mauvais et le très méchant

Les hacks CSS sont parfois appelés des filtres, mais ce sont tous des moyens de tromper un navigateur pour lui faire afficher quelque chose de la même manière qu'un autre (en général plus correctement), ou de cacher des sections de code à un ou plusieurs navigateurs. Ils sont répartis entre ce qu'on appelle les "bons" hacks, ou "valides", et les "mauvais" hacks, selon la façon dont ils travaillent. D'une manière générale, la syntaxe d'un bon hack respecte entièrement la spécification CSS, et son utilisation ne cause aucune erreur de validation. Les mauvais hacks sont écrits de manière illégale, par exemple à l'aide d'une syntaxe CSS incorrecte, et ne valideront pas.

Cela ne veut pas dire que la police de CSS viendra frapper à votre porte si vous écrivez un mauvais hack, mais mais attendez la suite. Des modifications dans le code d'un navigateur futur pourraient rendre inefficaces certains hacks aujourd'hui valides, tout en échouant à résoudre le problème que le hack évitait. Dans ce cas, un nouveau hack sera soudainement nécessaire. L'emploi de hacks invalides augmente fortement ce risque. Ça n'en vaut pas la peine.

Un exemple de hack valide est le hack « Tan » :

* html .truc {width: 100px;}

Ce code ne peut être vu et exécuté que dans les navigateurs IE (Windows et Mac) à cause de la construction du sélecteur précédant la déclaration propriété/valeur. Ce sélecteur indique spécifiquement :

Sélectionne un élément avec la classe .truc, quand il est contenu à l'intérieur d'un élément HTML, et que cet élément HTML est contenu dans n'importe quel autre élément, et donne-lui 100 pixels de largeur.

Les espaces entre les différentes parties du sélecteur sont d'une importance critique. Ils sont ce qu'on appelle des « combinateurs descendants ». Un combinateur descendant est un espace qui sépare deux sélecteurs simples ou plus, comme des noms d'éléments, des classes, etc. L'ordre dans lequel apparaissent ces sélecteurs simples détermine quel élément est sélectionné. Les classes, les ID, les sélecteurs d'attributs et les pseudo-classes peuvent être combinés avec des noms d'éléments en utilisant le combinateur descendant.

Selon la spécification HTML, HTML est supposé être « l'élément racine » à l'intérieur duquel résident tous les autres éléments. En conséquence, aucun autre élément ne peut entourer HTML, mais il se trouve que les navigateurs IE croient qu'il existe un tel élément ! Nous ne connaissons pas son nom, et Microsoft ne l'a jamais mentionné dans sa documentation, mais il existe sans aucun doute puisque tous les navigateurs IE obéissent à ce sélecteur.

L'important ici est que ce sélecteur est valide, car il suit une syntaxe et des règles de construction CSS correctes. Le fait qu'il repose sur un « élément racine mystère » entourant l'élément HTML ne signifie pas que ce sélecteur est illégal, mais seulement qu'il ne devrait en fait rien sélectionner du tout. Tous les navigateurs autres que Internet Explorer réalisent que la construction du sélecteur ne peut rien sélectionner, et ignorent donc toutes les déclarations suivant ce sélecteur.

Parlez-moi des mauvais hacks !

Un mauvais hack est par exemple celui qui utilise un caractère incorrect à un endroit étrange et invalide. Un navigateur respectueux des normes ignorera la règle de style, alors qu'un autre plus permissif lui obéira. Devinez quel navigateur est généralement le plus permissif ? Oui, vous avez tous trouvé, c'est ce bon vieux IE/Win. C'était trop facile.

Un grand nombre de caractères illégaux peuvent être directement placés devant un nom d'élément à l'intérieur d'un sélecteur, et IE/Win dira « Tranquille ! Ça a l'air tout bon pour moi ! » Les navigateurs plus au courant des normes ignoreront simplement toute la règle, comme le demandent les spécifications. Quelques tests révèleront plusieures façons de tromper IE/Win, mais tous ces hacks sont basés sur une syntaxe incorrecte tolérée par IE. Mauvais plan.

Quoi ? Vous voulez des infos sur les hacks « très méchants » ? Croyez-nous, vous vous porterez bien mieux sans !

« Contournement »

À l'inverse d'un hack, un contournement ne s'amuse pas avec le code. Un problème est « contourné » en trouvant une façon alternative de faire qui ne causera pas de souci. Il n'existe aucune liste magique de contournements, mais une fois qu'on sait jouer la gamme des effets de CSS, il est incroyable de voir comment un même effet peut être obtenu à l'aide d'une méthode complètement différente. Les familiers de la programmation comprendront ce que nous voulons dire.

De temps en temps, une difficulté surgit, et en employant une méthode différente on découvre que de nouvelles difficultés ralentissent la progression. Parfois, une troisième méthode est essayée, entraînant encore plus de problèmes étranges. Si cela vous arive, il vaut peut-être mieux reprendre la conception de votre design à la base. Nous n'insisterons pas sur ce conseil, mais beaucoup ont frôlé la crise de nerfs à force de se taper la tête contre de tels problèmes. Ne vous laissez pas entraîner trop loin jusqu'à en perdre le sens des perspectives, d'accord ?

Fiche technique

  • Article original : Webcoding Terminology
  • Auteur : Holly Bergevin et John Gallant
  • Date de parution : 23/03/2003
  • Traduction : Samuel Latchman
  • Date de traduction : mars 2005
  • Thème : Web design
  • Niveau : Tous niveaux

À propos de l'auteur

Holly Bergevin et John Gallant sont les animateurs du site Position Is Everything, où ils exposent les bugs CSS les plus obtus des navigateurs modernes, ainsi que des exemples concrets d’une utilisation efficace des feuilles de styles.


Pompage.net - CSS : on reprend tout à zéro !

Pourquoi les standards du Web sont importants

Par Carrie Bickner

Vous venez à peine d'inaugurer le nouveau site Web de votre bibliothèque que déjà, le téléphone n'arrête pas de sonner : "Je viens tout juste de télécharger la version la plus récente de Netscape et votre barre de navigation supérieure est invisible." ; "J'utilise un lecteur d'écran et votre site est tout simplement incompréhensible. Je n'arrive pas à y retrouver quoi que ce soit." ; "Je vous appelle de la part du Consortium des Bibliothèques du Tricounty ; nous apprécions tout le travail que vous avez accompli, mais nous aurions quelques questions à vous poser à propos de la charte graphique du nouveau site."

Le site (malgré des mois de durs labeurs, les meilleurs logiciels et des tests exhaustifs d'assurance qualité) souffre de sérieux problèmes. Pourquoi ? Comment remédier à la situation, tout en ne répétant pas les mêmes erreurs ? La solution se trouve dans l'adhésion à un ensemble de normes Web établies et mondialement reconnues.

Qu'est-ce que le W3C ?

Le Consortium du World Wide Web (W3C), fondé en 1994 par Tim Berners-Lee, est un consortium industriel international comptant plus de 300 membres. Sa principale raison d'être consiste à faire en sorte que les spécifications ouvertes qui y sont produites, communément surnommé les "standards du Web" encourageront l'interopérabilité. C'est aux membres du Consortium et à ses experts invités des différents groupes de travail que revient la responsabilité de rédiger ces spécifications. Une fois approuvées, ces idées sont alors promues au titre de recommandations officielles du W3C.

Le W3C a publié plus d'une quarantaine de recommandations depuis 1994. HTML, XHTML et CSS ne représentent qu'une petite portion du travail réalisé. Les autres recommandations incluent :

  • Les lignes directrices de l'accessibilité Web (Web Accessibility Guidelines) visant à favoriser l'accès au Web pour les personnes aux prises avec des limitations physiques. Ces principes sont également profitables pour l'ensemble des utilisateurs (ils sont en fait similaires aux lignes directrices pour l'accès mobile) ;
  • Scalable Vector Graphics (SVG), un format d'images basé sur XML. Les graphiques SVG sont éditables dans tout éditeur texte et peuvent être indexés par les moteurs de recherche ;
  • MathML, un outil pour baliser les formules mathématiques sur le Web, à l'aide de XML .

On retrouve parmi les membres du W3C des entreprises comme Netscape, Microsoft, Apple, Ask Jeeves, Cannon, DoubleClick, Ericsson et OCLC. L'adhésion d'OCLC repose sur le fait qu'il est essentiel pour la communauté des bibliothécaires de jouer un rôle prépondérant dans le développement et la gouvernance des standards du Web. Alors que les bibliothécaires se retrouvent dans une position où ils sont appelés à partager l'univers technologique avec une multitude de parties prenantes, nous éprouvons le besoin de promouvoir nos perspectives et nos valeurs.

Que sont les standards du Web ?

"Standards Web" est l'appellation utilisée par les développeurs Web pour faire référence aux spécifications et aux lignes directrices émises par le Consortium du World Wide Web (voir ci-contre). Ces lignes directrices, communément appelées "standards," couvrent plusieurs domaines, dont la sécurité et le cryptage sur le Web. Mais les recommandations pour les langages structurés comme HTML, XHTML , XML , ou encore, les langages de mise en page des documents comme CSS (Cascading Style Sheets - Feuilles de Style en Cascades), sont les aspects des normes qui devraient principalement intéresser les développeurs Web œvrant dans les bibliothèques.

En quelques mots, les guides du W3C pour le balisage des documents déterminent comment ceux-ci devraient être structurés et comment les récepteurs (incluant navigateurs, PDAs et interpréteurs Braille) devraient afficher leur balisage.

En ayant recours à XHTML pour la structure des documents et à CSS pour leur aspect, les bibliothécaires ont en main tous les atouts pour créer des sites qui sauront résister au passage du temps ainsi qu'à l'évolution éventuelle des navigateurs et autres agents utilisateurs, incluant toutes les technologies d'assistance. XHTML et CSS, les normes les plus récentes du W3C pour le balisage des documents et leur mise en page, offrent aux sites Web d'aujourd'hui une structure rigoureuse dont les interfaces Web, les moteurs de recherche, les systèmes de gestion de contenu et autres outils apparentés devraient pouvoir tirer avantage.

Par ailleurs, le recours à ces normes réduit considérablement les coûts associés à la production de sites Web, tout en assurant des économies substantielles quand arrive le temps des refontes. De plus, en tant que version allégée de XML , le XHTML est en mesure d'assister les développeurs Web dans une transition en douceur vers un XML déployé à grande échelle par le biais d'un langage de balisage enrichi, promettant aux sites Web un plus grand degré d'interopérabilité.

Supporter l'accès

La première étape pour réaliser des sites Web accessibles consiste à vous assurer d'utiliser du XHTML bien-formé. XHTML remplace la recommandation pour le HTML 4, qui elle même, remplaçait celle pour le HTML 3 et ainsi de suite. Chacune de ces recommandations est basée sur les fondements de la précédente. De manière générale, XHTML 1.0 conserve les bons éléments de HTML 4 tout en se débarrassant des moins bons. Plusieurs des exemples présentés ici faisaient également partie de HTML 4 ; qu'importe, les développeurs devraient apprendre à utiliser les normes les plus récentes.

La documentation du W3C est rédigée par et pour des programmeurs et peut s'avérer difficile d'accès pour un lecteur inexpérimenté. Les développeurs apprennent, dans une certaine mesure, à utiliser directement les recommandations à partir du site du W3C, mais aussi plus fréquemment, par l'intermédiaire d'autres développeurs, d'articles ou de bouquins. (Pour un coup de pouce, consultez "Une rapide entrée en matière pour XHTML")

Un des exemples les plus évidents des standards du W3C concerne l'attribut alt de l'élément image qui constitue un pré-requis pour XHTML 1, tout comme ça l'était également pour les versions de HTML 4. Nous savons tous que pour qu'un site s'affiche convenablement dans un navigateur non-graphique comme les lecteurs d'écran JAWS ou Window-Eyes, il importe de fournir une alternative textuelle pour les images de manière à permettre l'affichage conforme de leur contenu. Le XHTML valide exige que la moindre image présente dans un document Web inclue systématiquement un texte descriptif laissant savoir à quoi correspond l'image en question. Voici à quoi ressemble le code :

<img src="tiger.gif" width="245" height="46" alt="Une photo d'un tigre courant dans les rues de la ville de New York." />

Ce qui assure ainsi à l'utilisateur ayant recours à un lecteur d'écran la réception d'une description précise de l'image en question.

Le XHTML requiert également que les entêtes, listes et autres balises structurelles soient utilisées de manière à ce que les interpréteurs des technologies d'assistance puissent être en mesure de parcourir un document cohérent au travers duquel l'information est logiquement organisée. Ce n'est qu'un exemple parmi tant d'autres de la manière par laquelle les développeurs XHTML peuvent être incités à écrire des documents bien structurés, lesquels deviendront par là même des pages Web plus accessibles.

Une fausse impression, qui circule parmi les développeurs Web, et plus particulièrement parmi ceux appartenant à la communauté des bibliothécaires, est qu'il est impossible pour un site d'être à la fois visuellement très attractif et complètement accessible. Rien n'est plus faux. En fait, plusieurs éléments de design sophistiqués —variations subtiles de couleurs, multimédia, recours aux images de grande dimension— qui sont rejetés par certains défenseurs de l'accessibilité peuvent s'avérer être des améliorations substantielles pour le grand public et ne diminuent en rien l'expérience de personnes aux prises avec des limitations physiques s'ils sont utilisés efficacement. Un site Web au design des plus élaborés, bâti en harmonie avec les standards et les principes d'accessibilité, sera toujours un site accessible.

Créer l'interopérabilité

L'accessibilité n'est pas la seule raison justifiant l'intérêt que les bibliothécaires devraient avoir pour les langages de présentation basés sur les normes. Après tout, les bibliothèques et les bibliothécaires se sont de longue date engagés dans la création et le support de standards qui encouragent l'interopérabilité, la compatibilité et le partage des ressources.

L'enregistrement MARC s'avère être une bonne analogie pour le balisage structurel. Pourquoi le nom de l'auteur figure-t-il toujours dans le champ 100 d'un enregistrement MARC ? Tout simplement parce que le champ 100 indique au système la manière par laquelle l'information au sujet d'un auteur doit être organisée afin d'être convenablement présentée dans une variété de modes de consultation, incluant les catalogues de cartes imprimées et les écrans d'ordinateurs. Pour des besoins plus sophistiqués, le champ 100 nous permet de construire des applications capables de limiter les paramètres de recherche. Quiconque a ressenti, à un moment ou un autre, le besoin de limiter la recherche dans un catalogue au seul champ Auteur sait que c'est une excellente idée. Enfin, la spécificité d'un enregistrement MARC permet la mise en œuvre de services spécialisés comme la recherche inter-catalogues.

Le Web serait un meilleur endroit pour tout le monde si les forçats du code réfléchissaient plus en termes de catalogue. Conservant en mémoire l'analogie du champ 100, pensez seulement à l'élément HTML <title>, l'endroit où vous pouvez écrire le titre de votre document. Voici un exemple :

<title>Digital Web Magazine</title>

La plupart des navigateurs Web affichent le contenu de la balise <title> dans le coin supérieur gauche du navigateur. Les moteurs de recherche affichent ce même contenu lorsqu'une page est invoquée dans un ensemble de résultats de recherche. À la lointaine époque de Netscape 1.0, lorsqu'un développeur écrivait plus d'un élément <title>, Netscape 1.0 réagissait en bouclant sur chacun d'eux, simulant ainsi une jolie présentation visuelle enchaînée.

<title>Magazine Digital Web</title>

<title>Un magazine pour les développeurs Web</title>

<title>Ne manquez pas cette fabuleuse opportunité</title>

Dès les premières heures de Netscape 1.0, les développeurs devinrent habitués à écrire du code destiné à fonctionner dans les navigateurs primitifs et développèrent même des astuces visant à tirer avantage des faiblesses de ceux-ci. La multiplication des éléments <title> est un exemple classique qui est entré dans l'histoire. La tradition des astuces HTML est forte et la très grande majorité du code que l'on retrouve sur le Web aujourd'hui s'inspire largement de ces abus créatifs. Ce type de balisage était amusant et créatif, mais il était aussi très mauvais pour le Web. Comment les moteurs de recherche, les outils d'indexation et de confection de catalogues pouvaient-ils espérer déterminer le véritable titre d'un document ?

Nous ne faisons pas de classification en fonction de l'apparence de nos entrées sur un système donné ; nous classons en fonction d'une norme. Nous sommes conscients des avantages à court et long terme d'une classification normalisée. Toutefois, nous échouons souvent à voir les mêmes utilisations et avantages dans les standards du Web.

Je vous l'accorde, l'enregistrement MARC n'est pas entièrement analogue au XHTML, mais lorsque l'imposante machine sémantique nommée XML remplacera XHTML, nos sites pourront être aussi puissamment structurés qu'un enregistrement MARC. Les appareils et les programmes seront en mesure de tirer plein avantage de cette structuration d'une manière qui rendra tous les bibliothécaires très heureux. Le XML rendra possible une structure qui permettra de grandes opportunités en matière d'interopérabilité et de recherches avancées.

Contrôler la mise en page

Tout aussi importants que puissent être les aspects d'accessibilité et de compatibilité, les économies substantielles en temps et en argent sont des raisons toutes aussi séduisantes d'adopter les standards du Web.

Le W3C a créé et développé un langage de présentation nommé Cascading Style Sheet. La première spécification CSS fut rédigée en 1996. À cette époque, le support CSS dans les navigateurs était un rêve à atteindre, mais avec l'évolution des CSS, le support dans les navigateurs s'est grandement amélioré. Nous sommes désormais dans une position où nous pouvons enfin commencer à profiter de ce puissant outil.

Par le passé, les développeurs Web créaient des mises en page HTML qui étaient contrôlées par des images transparentes, des astuces HTML et des balises de formatage. Pour refaire un site construit de cette façon, chaque image, astuce et page devait être rééditée. Les CSS permettent aux concepteurs de contrôler la mise en page de tout un site à partir d'un seul et même document centralisé : la feuille de style.

Les CSS permettent de contrôler tous les aspects du design d'un site : typographie, couleur et mise en page. Les CSS peuvent même être utilisées pour créer des effets de déroulement. Par exemple, une zone d'un document peut être programmée de manière à ce que le texte et la couleur de fond changent au passage de la souris du visiteur. Ce type d'effet est habituellement réalisé avec des images et du javascript, mais il peut être réalisé beaucoup plus simplement avec CSS, et ce avec beaucoup moins de lignes de code. Cet exemple n'est qu'un aperçu de ce qui peut être réalisé avec CSS. En contrôlant tous les aspects de présentation d'un site avec une seule feuille de style, les CSS offrent un niveau de contrôle inégalé sur la mise en page d'un document XHML et ce, avec un indice de bande passante incroyablement peu élevé.

Un meilleur rendement pour votre argent

Si vous utilisez XHTML pour structurer vos documents Web et CSS pour en assurer la présentation, la refonte de votre site pourrait être aussi simple que de retravailler votre feuille de style. Vous n'aurez plus besoin de revoir l'ensemble de votre code pour chacune des pages de votre site et vous économiserez ainsi à votre bibliothèque du temps et de l'argent.

Par exemple, lorsque la très populaire police de caractère Verdana commencera à présenter des signes de vieillissement. Il suffira de remplacer "Verdana" par "Georgia" dans la feuille de style et le changement s'opérera instantanément à travers tout le site. Les couleurs, mises en page, bordures, ainsi qu'à peu près tous les autres éléments de design peuvent ainsi être aussi simplement maintenus.

Les deux designs suivants, www.roguelibrarian.net/lj/one_a.html et www.roguelibrarian.net/lj/two.html, utilisent exactement le même balisage (la même information structurée), mais chaque version appelle une feuille de style différente.

Si vous devez modifier l'apparence de votre site, ou s'il ne s'affiche pas immédiatement de manière correcte sur une nouvelle plateforme, les ajustements nécessaires seront bien moins contraignants. Il y a d'ailleurs de bonnes chances pour qu'il vous suffise de modifier une ou deux feuilles de style, ou peut-être juste d'en créer une nouvelle.

Navigateurs et appareils du futur

Au cours des deux dernières années, les navigateurs Web sont passés d'un mode de rendu propriétaire à un mode de rendu basé sur les normes. Jusqu'aux navigateurs de leur version 4.0, Netscape et Internet Explorer affichaient les pages Web selon des moteurs de rendu qui leur étaient propres. Le moteur de rendu de Netscape supportait certaines balises, tandis que celui de Microsoft en supportait d'autres. Chaque moteur possédait également sa propre manière bien personnelle d'interpréter le code, les développeurs se retrouvant bien souvent dans une situation les obligeant à concevoir deux sites, l'un spécifique à Netscape, l'autre à Internet Explorer.

Avec l'avènement de Netscape 6 et Internet Explorer 5, le support des standards s'est considérablement amélioré, de sorte qu'il est très facile pour les développeurs de prédire sans crainte de se tromper qu'un XHTML basé sur les normes fonctionnera bien avec les versions courantes de ces deux navigateurs. Le support des standards était pitoyable dans les navigateurs de version 4 et les bibliothèques qui persistent à utiliser les navigateurs de cette génération devraient envisager de les mettre à jour dans le cadre d'une transition vers un support des normes.

Si vous construisez votre site avec les standards Web, vous pouvez être raisonnablement sûrs que ceux-ci s'afficheront convenablement dans les navigateurs futurs. Si vous réalisez qu'une mise en page est problématique sur la nouvelle version d'un navigateur, la solution impliquera un simple ajustement de votre feuille de style, et non du code de l'ensemble de votre document. Rappelez-vous que les PDAs gagnent de plus en plus en popularité comme moyen d'accéder au Web. Peut-être que les ordinateurs mobiles deviendront la norme. Si notre contenu est bien orchestré avec un balisage conforme aux normes, il aura de bien meilleures chances de s'afficher convenablement dans les appareils du futur.

Une rapide entrée en matière pour XHTML

XHTML et CSS remplacent HTML et son ensemble de balises de formatage. XHTML et HTML sont très similaires, et la transition de HTML vers XHTML n'induit qu'une petite courbe d'apprentissage et un nouvelle façon de penser. Quant à l'apprentissage de CSS, c'est un petit peu plus compliqué.

Voici donc une approche en trois parties pour adopter XHTML :

  1. apprendre quelles sont les différences entre HTML et XHTML ;
  2. réfléchir sérieusement à la structure du document ;
  3. soumettre vos pages au validateur XHTML.

HTML contre XHTML

Opérer la transition de HTML vers XHTML n'est pas si difficile que ça. En fait, il n'y a que cinq facteurs principaux à prendre en compte :

A. Assurez vous que toutes les pages débutent par le DOCTYPE et l' espace de noms adéquat.

Les documents XHTML doivent commencer avec une balise qui indique au navigateur comment les interpréter. Les pages Web de toutes les bibliothèques devraient commencer par la déclaration DOCTYPE suivante :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

B. Ecrivez toutes les balises en minuscules.

HTML n'est pas sensible à la casse, mais XHTML l'est et demande à ce que tous les éléments <P> deviennent des éléments <p>, que les <TD> deviennent des <td>, et ainsi de suite. La plupart des éditeurs HTML vous permettront de définir l'écriture par défaut du balisage en minuscules.

C. Mettez tous vos attributs entre guillemets.

En HTML, vous n'avez pas besoin de mettre de guillemets autour des valeurs des attributs. Avec XHTML, celles-ci doivent être mise entre guillemets. Exemple : height="55" et non height=55.

D. Fermez tous les éléments.

En HTML, vous avez la possibilité d'ouvrir de nombreux éléments comme <p> et <li> sans avoir à les refermer. Mais en XHTML, chaque <p> doit être fermé par un </p>, et chaque <li> doit être fermé par un </li>.

E. Fermez les éléments "vides".

En XHTML, même les éléments vides comme <br> et <img> doivent être fermés en incluant un espace et une barre oblique à la fin de chacune de ces balises :

<br />
<img src="library.gif" />

Pensez à la structure du document

Comme tous les languages de balisage, XHTML est supposé donner une structure logique au document. Quand vous écrivez le code de vos documents, pensez en termes de plans traditionnels :

  • <h1>Sujet ou idée principale</h1>/
  • <p>Texte d'introduction.</p>
  • <h2>Sujet secondaire</h2>
  • <p>Texte du sujet secondaire.</p>

Évitez la tentation d'utiliser tous les éléments de formatage désapprouvés ou supprimés comme les balises <font> qui sont utilisées de manière erronée pour procurer une structure visuelle là où il n'existe aucune structure logique.

Ne faites pas ceci :

<p><font color="olive" size="7">Sujet ou idée principale</font>

Faites cela :

<h1>Sujet ou idée principale</h1>

Vous pourrez alors appliquer une feuille de style pour donner à l'élément <h1> un style particulier, de sorte qu'il s'affichera avec une couleur olive et une taille plus grande que celle du texte.

En balisant votre document, demandez-vous quelle information votre code enverra à l'appareil qui devra l'utiliser. Si vous vous retrouvez en train de créer une liste comme celle-ci :

un objet <br />
un autre objet <br />
un troisième objet <br />

Pensez plutôt à utiliser une liste ordonnée ou non ordonnée :

<ul>
<li>un objet</li>

<li>un autre objet</li>
<li>un troisième objet</li>
</ul>

La meta-information fournie par le balisage en apprendra plus à l'appareil qui va l'utiliser sur l'information qui lui est envoyée.

De plus, grâce à ce genre de liste, vous pouvez très simplement imbriquer des élements dans les autres :

<ul>
<li>un objet principal
<ul>
<li>un objet se rapportant au principal</li>

<li>unautreobjet se rapportant au principal</li>
</ul>

</li>
<li>un autre objet</li>
</ul>

Travaillez avec un validateur

La façon la plus rapide de vérifier votre code et d'apprendre XHTML est de valider vos pages. Le service de validation du W3C testera vos pages pour voir si celles-ci sont valides.

Comme le validateur d'accessibilité Bobby -un formulaire Web par lequel vous pouvez vérifier l'accessibilité de votre site- le validateur XHTML du W3C fonctionne aussi grâce à un formulaire Web. Passez votre URL dans la zone de saisie, sélectionnez Submit et le validateur testera votre page.

Si le document n'est pas valide, le validateur vous donnera une analyse des problèmes. Les premières validations peuvent être très frustrantes. Le rapport d'erreur est technique et identifie parfois la mauvaise erreur ; vous aurez peut être à faire un petit travail de détective.

Fiche technique

  • Article original : Why Web Standards matter
  • Auteur : Carrie Bickner
  • Date de parution : 15 juillet 2002
  • Traduction : Denis Boudreau
  • Date de traduction : septembre 2003


Pompage.net - CSS : on reprend tout à zéro !

On revoit les bases : la propriété « background »

Par Paul O’Brien

La propriété CSS background vous permet d'appliquer à tout élément de votre choix des couleurs ou des images de fond. Mais il y a plein de petits bugs et de défauts qui peuvent surprendre le développeur non averti.

D'abord c'est quoi un fond ?

Le fond d'un élément, c'est à la fois sa largeur et sa hauteur totales, y compris le remplissage et les bordures qui lui ont été appliqués. Cela ne comprend pas les marges de notre élément. Donc le fond d'un élément se trouvera en dessous du contenu de premier plan, y compris son remplissage (« padding »), et il sera également présent sous les bordures qui ont été déclarées.

Si un élément a des bordures transparentes, on doit pouvoir voir l'image qui se trouve en dessous. Notez toutefois que IE6 et ses prédécesseurs ne traitent pas les bordures transparentes, et de toutes façons le reste des règles est très mal interprété puisqu'ils considèrent que le fond s'arrête au bord intérieur des bordures.

Le mieux est de voir cela à travers un petit exemple que vous pouvez tester sous IE6 et Firefox pour comparer les différences.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Test de Fond</title>

<style type="text/css">

#test{
width: 100px;
height: 100px;
background: red;
border: 10px dashed green;
}

</style>
</head>
<body>

<div id="test">test</div>

</body>
</html>

J'ai choisi des bordures vertes et pointillées pour que vous puissiez voir le fond dans les intervalles. Comme on le voit, sous IE (y compris IE7) la couleur de fond n'atteint que la frontière intérieure de la bordure, alors que la plupart des autres navigateurs laissent glisser la couleur de fond sous la bordure jusqu'à atteindre la frontière extérieure du conteneur.

Au quotidien, c'est rarement un problème, mais cela reste une chose dont il faut être bien conscient.

Les propriétés du fond

Dans la plupart des cas, ce qui suit renvoie aussi bien aux éléments en bloc qu'aux éléments définis en ligne, à ceci près que la répétition et le positionnement de l'image de fond pour les éléments en ligne ne sont pas définis dans la spécification CSS2.1.

Voici les propriétés du fond :

  • background-color
  • background-image
  • background-repeat
  • background-position
  • background-attachment
  • inherit

Voyons les propriétés les unes après les autres, comment elles fonctionnent et quels sont leurs effets.

background-color

Valeurs possibles : couleur | transparent | inherit

Comme on peut s'en douter, c'est ainsi qu'on détermine la couleur de fond d'un élément. On peut la préciser de différentes façons :

background-color: #000000;

ou en groupes de trois chiffres :

background-color: #000;

Vous pouvez aussi utiliser l'un des mots-clés de couleurs disponibles :

background-color: red;

Ou enfin, vous pouvez choisir la méthode de couleurs rgb :

background-color: rgb(0,0,0);

(Le W3C en dit davantage sur les différentes méthodes pour appliquer une couleur.)

La valeur initiale (ou « par défaut ») du fond d'un élément est transparent, ce qui permet à un élément de venir se superposer à un autre, tout en permettant de toujours voir le fond par transparence. La plupart du temps, ce ne sera pas utile de le déclarer, sauf si on souhaite annuler une couleur de fond qui aurait été préalablement définie pour cet élément.

Au passage, je vous conseille de prendre l'habitude de toujours indiquer une couleur de premier plan en même temps qu'une couleur de fond, pour éviter le risque d'avoir une couleur identique ou quasi-identique entre le premier plan et le fond (soit par héritage de valeur, soit à cause des feuilles de style des utilisateurs). Même si ce n'est pas toujours possible (par exemple si votre fond est transparent), cela reste une idée à garder en tête et à vérifier au fur et à mesure du codage.

Quand on applique une couleur de fond background-color à un élément, il faut qu'une partie de cet élément soit visible pour qu'on puisse voir ce fond. Si l'élément n'a pas de hauteur (ce qui est le cas quand il ne contient que des éléments enfants placés en flottement), alors aucune couleur de fond ne sera visible. Il s'agit là d'une erreur courante chez les débutants, et il faut s'assurer que votre conteneur occupe bien de l'espace sur l'écran si vous voulez que le fond soit visible.

background-color: inherit; —inherit permet à l'élément d'hériter de la propriété background-color de son parent. On croit souvent par erreur que les couleurs de fond sont héritées par défaut, mais ce n'est pas le cas ; et lorsque l'on voit la couleur de fond du parent s'appliquer sur l'élément enfant, c'est parce que le fond de ce dernier est transparent.

background-image

Valeurs possibles : uri | none | inherit

La propriété background-image vous permet de placer une image dans le fond de l'élément concerné. La seule chose à faire est d'indiquer le bon chemin vers l'image :

background-image:url(image-d-exemple.gif);

Notez que le chemin de l'image est relatif à l'emplacement du fichier CSS, et non pas à la page HTML qui l'appelle, donc assurez-vous que vous indiquez le bon emplacement ; dans notre exemple, si on suppose que notre CSS est placée dans un dossier /css, nous indiquons une image située dans le dossier /images qui est au même niveau que le dossier CSS :

background-image:url(../images/image-d-exemple.gif);

Il n'est pas nécessaire d'entourer l'url avec des doubles guillemets (ils sont optionnels) mais leur emploi est valide :

background-image:url("../images/image-d-exemple.gif");

Les guillemets simples (') sont également autorisés, mais ils déclenchent un bug sous IE5/Mac qui empêchera complètement l'affichage de vos images.

Par défaut, l'image sera placée dans le coin supérieur gauche de l'élément et en mosaïque (c'est-à-dire qu'elle sera répétée). Elle sera solidaire du document si on fait dérouler la page. Il s'agit là de réglages par défaut, mais vous pouvez les adapter avec des propriétés spécifiques. Voici un exemple basique d'une image de fond appliquée à l'élément body.

body {
  margin: 0;
  padding: 0;
  background-image: url(images/etoile.jpg);
}

Le code ci-dessus va disposer notre image d'étoile en mosaïque, en commençant par le coin supérieur gauche de la page et en continuant jusqu'à ce que la fin de la ligne soit atteinte. Puis une nouvelle ligne sera disposée en mosaïque en dessous, et ainsi de suite jusqu'à ce que tout l'élément body soit rempli.

Remarquez que l'image est coupée en fin de ligne, et c'est une nouvelle image complète qui apparaît à la ligne suivante. Il n'y a aucun moyen de régler l'écartement de la mosaïque (sauf en ajoutant de l'espace sur l'image elle-même).

Le fait de placer une image de fond n'aura aucun effet sur la taille de l'élément, donc il faut vous assurer qu'il y a suffisamment de hauteur et de largeur pour que l'image puisse être vue, ou bien suffisamment de contenu pour étirer les limites du conteneur.

background-image: none;— assez facile à deviner... permet tout simplement de s'assurer qu'aucune image ne sera affichée en fond d'élément.

background-image: inherit;— pour pouvoir hériter de l'image de fond d'un élément parent, la valeur inherit est possible mais elle est rarement utilisée. Les images se retrouvent en couches successives, celle de l'élément enfant recouvrant celle du parent ; tout cela peut tourner au fouillis, dans la mesure où les images ne seront pas parfaitement alignées.

background-repeat

Valeurs possibles : repeat | repeat-x | repeat-y | no-repeat | inherit

Cette propriété vous permet de définir la direction dans laquelle l'image de fond sera répétée, ou bien de l'empêcher de se répéter.

background-repeat: repeat;— La valeur par défaut répète l'image, à la fois sur l'axe horizontal et sur l'axe vertical. (Cela ne signifie pas que l'image est seulement répétée de gauche à droite et du haut vers le bas, mais qu'elle est répétée le long des deux axes, dans les deux directions, et ce jusqu'à ce que toute la zone soit couverte comme dans l'image 1 ci-dessus.)

background-repeat: repeat-x;— En donnant la valeur repeat-x, l'image sera uniquement répétée dans le sens horizontal. La répétition s'effectue dans les deux directions de l'horizontale, jusqu'à ce que toute la rangée soit couverte. La position de départ est par défaut en haut et à gauche, mais cela peut être changé : voir background-position plus bas.

Comme on le voit sur l'image ci-dessus, seul l'axe des x (horizontal) est rempli par notre image d'étoile.

background-repeat: repeat-y;— Ceci donnera l'effet inverse de repeat-x : au lieu de se répéter horizontalement, l'image ne se répètera que sur l'axe vertical. Comme précédemment, l'image sera placée en mosaïque vers le haut et le bas de l'axe vertical jusqu'à ce que toute la colonne soit pleine.

background-repeat: no-repeat;— Ceci empêche le positionnement en mosaïque. L'image est alors placée à la position indiquée par background-position, mais si aucune position n'est indiquée, ce sera par défaut le coin supérieur gauche de l'élément.

background-repeat: inherit;— L'élément hérite de la propriété background-repeat de son parent, mais en principe ce n'est pas quelque chose qu'on utilise de façon courante.

background-position

Valeurs possibles : unités de longueur fixes (par ex. pixels) | pourcentages | mots-clés

Quand on place une image de fond, on peut indiquer sa position de départ de plusieurs façons, la plus simple étant d'indiquer la position exacte en pixels.

background-position: 100px 200px;— Le coin supérieur gauche de l'image sera placé à 100px du côté gauche de l'élément, et à 200px sous son côté supérieur ; la position est toujours donnée avec d'abord l'horizontale, puis la verticale. Si une seule valeur est utilisée, on considère que cela ne concerne que la position horizontale, et la verticale restera par défaut à cinquante pour cent.

Conjointement avec un arrière-plan en mosaïque (voir images plus haut), la position que l'on indique est celle où l'image va d'abord être placée, avant de se trouver répétée le long des axes horizontaux ou verticaux selon le type de background-repeat qui a été choisi. L'image se répétera dans les deux sens le long de chaque axe.

background-position: 50% 100%;— Lorsqu'on utilise les pourcentages pour placer une image de fond, les choses sont gérées de manière un peu différente. La mesure en pourcentage ne renvoie pas uniquement à la position au sein de l'élément lui-même, mais également à ce point précis à l'intérieur de l'image. Si vous deviez indiquer background-position: 50% 100%;, la position horizontale à 50% de l'image (c'est-à-dire son axe central) serait alignée avec la position horizontale à 50% de l'élément, tandis que la verticale à 100% de l'image (c'est-à-dire le bas) serait alignée avec la verticale à 100% de l'élément (son côté inférieur).

Pour mieux expliquer, comparons background-position: 50% 50%; à son équivalent si nous étions en positionnement absolu. Si vous indiquez un position: absolute avec left: 50% et top: 50%, cela déplacera le coin supérieur gauche de l'élément au milieu de son parent : l'élément lui-même ne sera pas centré, il se situera alors dans le quart inférieur droit de son parent.

En revanche, quand les pourcentages sont utilisés dans la propriété background-position, cela ne renvoie pas au coin supérieur gauche de l'élément, mais au pourcentage correspondant pour l'image elle-même, ce qui signifie que background-position: 50% 50%; placera l'image parfaitement au centre de l'élément-parent.

En bas, l'image de fond a été placée à top: 50% et left: 50% ce qui aligne le coin supérieur gauche de l'image avec le milieu exact de l'élément. L'image de fond en haut est placée à 50% 50% et, comme vous pouvez le constater, le centre de l'image correspond exactement au centre du conteneur.

Dommage d'ailleurs qu'il n'existe pas une méthode aussi efficace pour les images de premier plan ou pour les éléments en bloc...

Comme vous l'avez sûrement compris maintenant, le choix de background-position: 100% 100%; place la position 100% de l'image (son coin inférieur droit) juste sur la position à 100% de l'élément (son coin inférieur droit à lui aussi), ce qui permet à l'enfant de se blottir juste dans le coin de son parent.

Vous pouvez aussi mélanger pixels et pourcentages si c'est nécessaire :

background-position: 50% 200px;

Désormais, il est également autorisé de mélanger les mots-clés (voir ci-dessous) et les valeurs en pourcentage ou en pixels (c'est là un point modifié dans CSS2.1, et qui n'était pas autorisé jusqu'alors). Je ne recommande pourtant pas de les mélanger, car seuls les navigateurs modernes sauront l'interpréter ; il n'y a pas d'avantage réel, dans la mesure où on peut tout simplement utiliser à la place les mesures équivalentes en pourcentages.

Mots-clés

Il existe aussi plusieurs mots-clés utilisables pour placer l'image de fond : pour la position horizontale on peut utiliser left, center, ou right, et pour la position verticale on peut choisir entre top, center ou bottom.

Cela signifie que pour situer une image en haut et à gauche d'une page, on peut utiliser background-position: left top;

Voici la liste complète.

  • background-position: left top; /* équivaut à 0% 0% */
  • background-position: left center; /* équivaut à 0% 50% */
  • background-position: left bottom; /* équivaut à 0% 100% */
  • background-position: right top; /* équivaut à 100% 0% */
  • background-position: right center; /* équivaut à 100% 50% */
  • background-position: right bottom; /* équivaut à 100% 100% */
  • background-position: center top; /* équivaut à 50% 0% */
  • background-position: center center; /* équivaut à 50% 50% */
  • background-position: center bottom; /* équivaut à 50% 100% */

Contrairement aux unités de longueur, il n'est pas utile de maintenir les mots-clés dans un ordre horizontal-vertical précis. On peut ainsi indiquer par exemple background-position: top left; au lieu de background-position: left top;.

Si on n'utilise qu'un seul mot-clé au lieu de deux, voici ce que cela va donner :

  • background-position: top; /* équivaut à 50% 0% */
  • background-position: left; /* équivaut à 0% 50% */
  • background-position: center; /* équivaut à 50% 50% */
  • background-position: right; /* équivaut à 100% 50% */
  • background-position: bottom; /* équivaut à 50% 100% */

background-attachment

Valeurs possibles : scroll | fixed | inherit

background-attachment: scroll;— La propriété background-attachment sert à déterminer si l'image de fond peut dérouler verticalement en même temps que le document ou bien si elle reste fixe. Par défaut, la valeur est scroll, ce qui signifie que si on fait dérouler le document vers le haut ou vers le bas, l'image montera et descendra en même temps.

Le seul cas où l'image ne déroule pas, c'est lorsqu'elle est placée dans un conteneur auquel on a attribué la valeur overflow: auto. L'image déroule alors, non pas en conjonction avec le conteneur mais avec l'ensemble du document. Le contenu du conteneur lui-même déroule par-dessus l'image, qui reste fixe et visible au sein de ce conteneur. IE6 et IE7 fonctionnent différemment sur ce point, en faisant dérouler l'image à l'intérieur du conteneur. Je rentrerai dans les détails plus loin en expliquant la valeur fixed, car on y verra des informations qui concernent à la fois les valeurs fixed et scroll.

background-attachment: fixed;— L'emploi de la valeur fixed va fixer une image en position dans le document, de façon à ce que l'image ne bouge pas du tout même si on fait dérouler le document vers le haut ou vers le bas, mais reste au contraire à sa place de départ (relative à la fenêtre d'affichage). Donc si on place une image dans le fond de <body> à 50% 50%, tout en utilisant la valeur fixed, l'image reste attachée au centre de la fenêtre d'affichage même si le document lui-même déroule vers le haut ou vers le bas. C'est assez utile si vous voulez avoir une image de fond et qu'elle reste toujours visible, indépendamment du contenu qui pourrait se dérouler.

Malheureusement, la valeur fixed se révèle un peu plus compliquée à utiliser lorsqu'on l'emploie sur d'autres éléments que body, et le concept peut être un peu difficile à comprendre au premier abord.

Le principe de base (et celui qui pose le plus de problèmes) est qu'une image de fond est toujours placée par rapport à la fenêtre d'affichage, et pas par rapport à l'élément dans lequel elle réside.

Réfléchissez bien à ce point pendant un instant, imprégnez-vous de l'idée.

NB : il faut préciser tout de suite que l'explication qui suit ne s'applique pas à IE6 ni aux versions précédentes, qui respectent très mal les règles sur ce point précis, j'y reviendrai. IE7, en revanche, suit bien le format expliqué ci-dessous.

Si vous avez un élément qui est centré sur la page, et que vous indiquez une background-position de 10px 10px en vous attendant à ce que l'image soit à 10px du coin supérieur gauche de cet élément, eh bien... vous avez tort. La position 10px 10px est toujours donnée par rapport à la fenêtre d'affichage, et donc l'image sera placée à 10px du coin supérieur gauche de votre fenêtre d'affichage, ce qui peut se révéler très éloigné de l'élément dans lequel vous l'aviez placé ! Il y a de grandes chances pour que vous pensiez que l'image ait disparu, car elle n'apparaîtra que lorsque l'élément dans laquelle elle réside se trouvera placé dans la fenêtre d'affichage dans la même position que celle indiquée par background-position.

Houlà, c'est bien compliqué tout ça...

Voyons un exemple pour éclaircir ce point. Je vais placer un élément de façon absolue à 100px du coin supérieur gauche de la page, et y appliquer background-image: fixed; à 10px 10px comme ceci :

#element_eloigne {
  position: absolute;
  left: 50px;
  top: 100px;
  width: 200px;
  height: 200px;
  background: url(images/dw-star.jpg) no-repeat fixed 10px 10px;
  border: 1px solid red;
}

Voici le résultat du code ci-dessus (sous Firefox 2.0) :

On dirait que l'image a disparu, comme je l'avais annoncé. Bien sûr, en réalité elle n'a pas disparu ; mais comme elle a été placée à 10px 10px par rapport à la fenêtre d'affichage, elle ne sera visible que lorsque l'élément (entouré de rouge dans l'image ci-dessus) sera installé à cette même position de 10px 10px. Pour que les choses soient plus claires, plaçons plutôt la boîte entourée de rouge à 30px du haut de l'écran.

#element_eloigne {
  position: absolute;
  left: 50px;
  top: 30px;
  width: 200px;
  height: 200px;
  background: url(images/dw-star.jpg) no-repeat fixed 10px 10px;
  border: 1px solid red;
}

Ah, voilà ! Maintenant, il devient possible de voir une partie de l'image parce que notre boîte rouge est venue recouvrir la position de fond où notre image a été placée. Et si on déplace la boîte rouge jusqu'à la position 10px 10px, c'est toute l'image qui devient visible.

À quoi ça sert tout ça ? Et qu'est-ce qu'on fait pour IE6 ?

Maintenant que vous savez comment trouver votre image de fond en position fixed, vous vous demandez peut-être : « En quoi et comment tout ça peut m'être utile ? »

Nous devons d'abord comprendre la façon dont IE6 (et ses prédécesseurs) se comporte, et il nous faut un autre exemple.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Document sans titre</title>
    <style type="text/css">
      * {margin:0;padding:0}
      #element_eloigne {
        position: absolute;
        left: 100px;
        top: 100px;
        width: 400px;
        height: 300px;
        background: url(images/volcano-1.jpg) no-repeat fixed 10px 10px;
        border: 1px solid red;
      }
    </style>
  </head>
  <body>
    <div id="element_eloigne">
      <p>test</p>
    </div>
  </body>
</html>

L'image est placée à l'intérieur de #element_eloigne et on a indiqué fixed pour son background-attachment. La position 10px 10px va situer l'image au coin supérieur gauche de la fenêtre d'affichage (et non pas au coin de #element_eloigne, j'espère que vous avez bien suivi !).

Regardez cet exemple de positionnement fixe, à voir d'abord sous IE6 puis sous Firefox (ou tout autre navigateur moderne). Si vous ne disposez pas de ces deux navigateurs, voici des impressions d'écran pour que vous puissiez voir les différences :

Comme on le voit, sous Firefox seule la partie de l'image qui coïncide avec la position de #element_eloigne est révélée. Le reste de l'image reste dissimulé.

IE6 et ses prédécesseurs, eux, font tout de travers et placent l'image en haut et à gauche (à 10px 10px) de #element_eloigne et non pas de la fenêtre d'affichage. Le problème est que l'image reste fixée en position, et si du contenu devait dérouler au sein de ce conteneur rouge, l'image ne bougerait pas et le contenu déroulerait par-dessus.

Malgré tout, l'image ne restera pas en place si tout le document déroule : la boîte rouge va dérouler et disparaître de la page (avec l'image). En fait, le comportement que l'on constate en utilisant fixed pour IE est similaire à celui que l'on obtiendrait sous Firefox si on avait utilisé le scroll par défaut au lieu de fixed. Comme si tout ça n'était pas déjà assez compliqué !

Sous Firefox, une image placée en fond d'élément avec scroll (la valeur par défaut) restera toujours visible dans le conteneur. Si overflow: auto a été appliqué au conteneur, et si les barres de défilement sont actives, l'image ne déroulera pas ; seul le contenu de premier plan défilera, laissant l'image visible en permanence. Toutefois, le même scroll sous IE6 va faire défiler l'image dans ce conteneur avec le contenu et disparaître avec lui le cas échéant.

À l'aide du code suivant, nous pouvons provoquer ces deux comportements différents dans nos navigateurs préférés

background: url(images/dw-star.jpg) no-repeat scroll 10px 10px;

Pour que IE6 se comporte comme Firefox quand on applique scroll, il faudrait utiliser à la place la valeur fixed (avec un « hack » ou un commentaire conditionnel pour ne cibler que IE6), mais il n'y a aucune façon de faire en sorte qu'IE6 interprète correctement la valeur fixed comme avec Firefox.

J'ai indiqué plus haut que IE7 comprend désormais la valeur fixed, mais du coup, cela provoque un comportement très particulier quand scroll est employé : IE7 se comporte comme IE6 et laisse l'image défiler au sein du conteneur (contrairement à d'autres navigateurs qui laissent l'image visible dans le conteneur même si le contenu de premier plan défile), donc sous IE7 il n'y a aucun moyen de laisser l'image visible au sein d'un conteneur que l'on fait dérouler (comme dans l'exemple ci-dessus avec Firefox). Si on utilise fixed, alors l'image est fixée par rapport à la fenêtre d'affichage, mais si on utilise scroll, alors l'image déroule avec son conteneur. Conclusion : IE7 interprète background-attachment: fixed correctement, mais pas scroll.

On peut encore parler d'autres associations de comportements quand on emploie fixed : qu'arrive-t-il à une image ainsi fixée lorsque le document défile, et que l'élément qui contient l'image fixée défile lui aussi ?

J'ai fait défiler le conteneur ainsi que le document et, comme vous le voyez, l'image avec la valeur fixed n'a pas bougé du tout sous Firefox. Le conteneur parent glisse par-dessus l'image, en révélant progressivement des morceaux de celle-ci en passant au dessus, mais l'image elle-même ne bouge jamais ; il n'y a que lorsque le conteneur passe au-dessus qu'elle est visible. IE7 se comporte exactement de la même façon sur ce point.

IE6, en revanche, garde l'image fixe au sein du conteneur parent, mais dès qu'on fait dérouler le document, le tout disparaît vers le haut.

La conclusion logique de tout cela est qu'on ne peut utiliser background-attachment: fixed de manière identique pour tous les navigateurs que si on l'applique à l'élément <body>, car c'est le seul moment où IE6 l'interprète correctement. Bien sûr, dès lors que vous en connaissez les limites, vous pouvez toujours utiliser les commentaires conditionnels pour donner à IE la version de base, et permettre aux bons navigateurs d'avoir la bonne version.

Inherit

Quand on utilise background: inherit, l'élément va hériter des propriétés de fond de son parent. C'est rarement une bonne chose à faire. La valeur par défaut du fond d'un élément étant transparent, le fond du parent sera déjà visible dans l'élément enfant. Il n'y a donc aucun besoin de préciser inherit.

IE6 et Safari 2.0 ont également un petit bug lié à background: inherit puisque background: inherit n'actualise pas la couleur de fond.

Raccourcis

En CSS, la propriété background est un raccourci qui permet d'indiquer plusieurs styles de fond pour un même élément en une seule fois. Vous avez peut-être remarqué que dans certains des exemples précédents j'ai utilisé la version raccourcie pour définir toutes les propriétés de fond d'un coup.

On peut économiser beaucoup de code et de temps à l'aide des raccourcis CSS, et je les utilise moi-même dès que possible. Prenez ce code par exemple :

#test {
  background-color: #000;
  background-image: url(nom_de_l_image.jpg);
  background-position: 10px 10px;
  background-repeat: no-repeat;
  background-attachment: fixed;
}

On peut le réduire à une seule ligne :

#test {
  background: #000 url(nom_de_l_image.jpg) no-repeat fixed 10px 10px;
}

Ça économise pas mal de code, donc ça en vaut vraiment la peine.

Une chose qu'il ne faut pas oublier quand on emploie les raccourcis (et cela vaut pour tous les éléments raccourcis), c'est que toutes les propriétés qui ne sont pas intégrées dans le raccourci recevront leurs valeurs par défaut. Donc avec une règle comme celle-ci :

#test {
  background-color: red;
  background: url(nom_de_l_image.jpg);
}

La couleur rouge (red) ne sera pas appliquée, parce que la ligne qui suit, en style raccourci, remet la couleur à sa valeur par défaut (c'est-à-dire transparent) dès lors qu'elle n'a pas été explicitement précisée. C'est également vrai de toutes les valeurs qui n'ont pas été précisées dans cette règle : toutes les propriétés non précisées reviendront à leurs valeurs initiales par défaut, annulant ainsi toutes les règles préalablement données.

Dans le raccourci, peu importe l'ordre dans lequel vous placez la plupart des propriétés de fond puisque le navigateur les reconnaîtra de toutes façons, mais le format courant est généralement celui-ci :

background: #000 url(nom_de_l_image.jpg) no-repeat fixed 10px 10px;

(Bien sûr, l'ordre dans lequel vous indiquez les coordonnées de background-position a par contre une importance puisque celles-ci seront appliquées d'abord pour l'horizontale, et ensuite pour la verticale. Voyez ci-dessus la partie qui traite de background-position pour davantage de détails.)

Résumé

Nous avons traité de la plupart des points liés à la propriété background et à ses valeurs associées, et en usage courant ces propriétés CSS peuvent vous donner beaucoup de contrôle sur l'aspect des éléments de votre design. Comme vous le voyez, la propriété background est très polyvalente. On peut en faire de très belles choses, et (avec un peu d'imagination) produire des effets très impressionnants.

Fiche technique

  • Article original : Web Design 101: Backgrounds
  • Auteur : Paul O’Brien
  • Date de parution : mai 2007
  • Traduction : Frédéric Chotard
  • Date de traduction : avril 2008
  • Thème : CSS
  • Niveau : Débutant

À propos de l'auteur

Paul O’Brien est un designer Web indépendant né à Londres qui, comme on peut le voir sur son site www.pmob.co.uk, s’intéresse particulièrement aux CSS. Outre l’article que nous traduisons ici, il a publié plusieurs fois sur digital-web.com. Sa phrase fétiche : « Hope that helps ! » (J’espère que je vous ai été utile...)


Pompage.net - CSS : on reprend tout à zéro !

Les pixels, voilà l’ennemi !

Par Dave Rupert

Les résolutions d’écran des appareils mobiles ne cessent d’augmenter, et on voit la même tendance pour les ordinateurs de bureau et les portables. On ne pourra pas y couper : l’affichage à haute densité de pixels (alias « Retina ») devient maintenant la norme ; et on voit bien que nos sites web conçus pour du LCD traditionnel commencent à faire grise mine. Mais plutôt que nous jeter à corps perdu dans le développement de sites de plus en plus gros, nous ferions mieux d’identifier les problèmes qui se présentent à nous et de trouver les solutions d’avenir les plus raisonnables, tout en gardant prioritairement à l’esprit nos utilisateurs.

Le problème majeur : des images énormes

Comme la plupart d’entre nous voulons toujours avoir une longueur d’avance, nous avons commencé à faire des sites web « @2× » [en proposant au départ des images deux fois plus grandes, pour ensuite les réduire de 50%, NdT] mais en espérant quand même que l’@3× ne serait pas pour demain. Bien qu’on puisse croire qu’une image @2× pèse deux fois plus de kilobytes, en réalité on arrive à environ trois ou quatre fois plus. Comme vous le verrez dans ma démonstration sur @1× contre @2×, pour des photos ou des compositions très détaillées on se retrouve rapidement avec non plus des kilobytes mais des mégabytes.

Je vous entends déjà répliquer : « Et alors ? Le web, ça doit être beau, non ? » Et je suis bien d’accord. C’est même souvent pour ça qu’on a choisi ce métier, pour faire du beau web. Mais là où le bât blesse, c’est dans l’idée qu’on se fait de la bande passante disponible.

Dans les pays riches, on a tendance à considérer que l’accès à une bande passante à haut débit est un droit, alors que pour beaucoup de gens dans le monde la bande passante est limitée, ou bien payante selon le débit téléchargé. Même si vous vous dites que « c’est pour faire plus beau », ce n’est pas une raison suffisante pour envoyer une image de 1 MegaBit à travers un réseau 3G ou, Dieu nous préserve, quelque chose comme un réseau Edge.

Et même dans nos petits paradis du haut débit, on n’a pas à chercher loin pour trouver des exemples de bande passante limitée. Un visiteur peut accéder à votre site avec une tablette ou un téléphone à haute définition qu’il soit confortablement installé sur son canapé, ou au milieu du désert de l’Arizona. De même, leurs Macbook Pro Retina flambant neufs peuvent très bien être connectés à Internet via un réseau Google Fiber, ou accrocher péniblement le signal d’un hotspot d’aéroport. Il est dangereux de croire qu’un écran à haute densité implique une bande passante illimitée.

La mauvaise solution : le JavaScript

« Eh bien moi, je vais mettre un petit JavaScript. »
— Signé : la terre entière

JavaScript nous a tellement souvent sauvé la mise par le passé qu’on est tenté d’implorer son secours une fois de plus. Néanmoins, la plupart des solutions ne donnent pas satisfaction, et finissent par imposer aux utilisateurs le fameux « double téléchargement ».

Mat Marquis a déjà expliqué tout ça, mais ça vaut la peine de le répéter : obsédés par une recherche incessante de vitesse sur le web, les navigateurs ont entrepris de pré-charger toutes les images d’un document avant même que le JavaScript puisse entrer en jeu et effectuer le moindre changement.

Du coup, dans le cas de solutions qui peuvent admettre de hautes résolutions et pour lesquelles une deuxième source d’images est injectée, les navigateurs vont chercher non plus une mais deux images, obligeant ainsi les utilisateurs équipés en haute résolution à attendre que les deux jeux d’images soient téléchargés. Ce double téléchargement n’est pas vraiment pénalisant quand il ne s’agit que d’une seule image, mais imaginez ce que ça peut donner à l’échelle d’une galerie photo contenant 100 images par page. Ça fait mal.

Il existe d’autres pistes, comme la détection de bande passante, le réglage des cookies, la détection côté serveur, ou bien un mélange des trois. C’est bien beau de laisser des machines s’occuper de régler tous nos problèmes, mais en réalité, pour le développeur web lambda, ces différentes solutions vont poser plus de problèmes qu’en résoudre. Leur plus gros défaut commun réside dans l’interdépendance serveur/cookie, dont on sait bien que c’est source d’ennuis.

Ce qu’il nous faudrait plutôt, c’est une solution à 100% côté client pour les images à haute résolution.

Et ça vous rappelle quelque chose, ça ? Si oui, c’est parce que les images à haute résolution et les images réactives renvoient à la même question de base : comment fournir différentes images à différents appareils et dans différents contextes, tout en employant la même et unique balise HTML.

La bonne vieille solution des familles : l’enrichissement progressif

Ceux qui parmi nous travaillent sur la question des CSS et des normes du web connaissent depuis longtemps le concept d’enrichissement progressif. Dans ce domaine, il faut vraiment que nous visions tous le même objectif. Peu importe le type de terminal qui les reçoit, peu importe la capacité de leur écran : quand on parle de pixels, on parle d’un élément d’enrichissement qui sera affiché par certains navigateurs, et pas par d’autres. Il faut mettre en place une base commune solide, puis procéder à des améliorations selon les besoins rencontrés. En fait, c’est en apprenant à construire correctement un site à enrichissement progressif que vous (et vos clients) pourrez en fin de compte gagner beaucoup de temps.

Voici les règles que nous suivons avec mes collègues de Paravel, et qui nous guident dans la jungle des images à haute résolution sur le web :

  • utiliser CSS et des polices web en priorité
  • employer le format SVG et les polices d’icônes quand c’est utile
  • pour les images non vectorielles, passer par Picturefill en JavaScript.

Examinons chaque règle en détail.

Les CSS et les polices web

Grâce à CSS3, nous pouvons reproduire assez facilement dans les navigateurs des effets visuels plus riches, et l’explosion des polices de caractère adaptées au web nous permet de construire des sites en nous appuyant sur une typographie riche, et non plus sur des collages d’images. Avec ce que nous offrent aujourd’hui les CSS, nous avons de moins en moins de raisons de nous baser sur des images géantes pour obtenir l’impact visuel recherché.

On en revient donc à la bonne vieille règle : s’il est possible de réaliser le design de votre site avec HTML et CSS, faites-le. Et si cela ne semble pas possible, commencez par vous poser la bonne question : pourquoi donc ? Après tout, si nous nous considérons comme des professionnels du design pour le web, alors il est impératif que nos designs fonctionnent avant tout pour le web — et de la façon la plus efficace possible.

Prenez du recul et appréciez de travailler avec ce qui fait la chair et le sang du Web : HTML et CSS.

Le format SVG et les polices d’icônes

Les images SVG sont des chemins vectoriels définis dans un document en XML ; elles ont été conçues comme une alternative au format Flash. Elles fonctionnent comme des fichiers Illustrator dans un navigateur. Non seulement elles ne dépendent pas du tout de la résolution des écrans, mais en plus elles produisent généralement des fichiers extrêmement légers (en fonction du nombre de points dans le vecteur).

Les polices d’icônes (comme Pictos ou SymbolSet) consistent pour l’essentiel en des collections de graphiques vectoriels, rassemblés dans des polices de casseaux (dingbats) sur mesure qui sont intégrées aux pages à travers des caractères unicodes, dans des fontes embarquées via @font-face. Une remarque en passant : à Paravel, nous avons remarqué que les petites images vectorielles comme les boutons et les icônes offrent un moins bon rendu sur les écrans à haute résolution. Les polices d’icône offrent une bonne alternative aux Sprites CSS, et nous avons d’ailleurs commencé à les utiliser en substitution dès que possible.

La déclaration @font-face est très bien interprétée, et on peut dire que la possibilité d’intégrer du SVG est devenue quasi-universelle — sauf bien sûr pour les suspects habituels, c’est-à-dire les versions anciennes d’IE et d’Android. Reste qu’aujourd’hui nous pouvons sans risque commencer à employer du SVG, quitte à faire quelques concessions aux navigateurs plus anciens si nécessaire, en les détectant puis en leur fournissant un script d’émulation de la fonction manquante (polyfill) ou bien un affichage alternatif (fallback), voire en utilisant un de ces nouveaux projets qui automatisent les Sprites SVG/PNG.

Mais il existe des cas où ces formats ne font pas l’affaire. Par exemple, les polices d’icônes ne fonctionnent qu’en une seule couleur. D’autre part, même si les SVG sont agrandissables à l’infini, qui dit agrandissement ne dit pas plus haute fidélité ni plus haut niveau de détail. C’est là que nous devons sortir l’artillerie lourde.

Images bitmap et Picturefill

L’élément <picture>, mis en avant par le Groupe Images Réactives du W3C et qui n’est pas inconnu des familiers de ce site (le site A List Apart, Ndt), constitue une solution élégante au chargement de grandes images bitmap. Avec <picture>, nous pouvons indiquer progressivement quelle est la source d’images à choisir par le navigateur, en fonction du nombre de pixels disponible.

L’élément <picture> n’est pas exempt de critiques, d’autant qu’il a un concurrent de poids. L’attribut d’image @srcset, qui est notamment poussé par Apple, se base sur la propriété CSS image-set() et vise à fournir des éléments haute-résolution en tant qu’images de fond. Voici un exemple de la syntaxe proposée (avec mes commentaires personnels) :

<img alt="Un chat qui danse" src="small-1.jpg"
srcset="small-2.jpg 2x,  // ça c’est plutôt bien
large-2.jpg 100w,       // bof...
large-2.jpg 100w 2x     // bof bof...
">

L’attribut @srcset se présente comme une solution complète pour les images réactives, mais sa microsyntaxe est pénible, et il n’est pas suffisamment universel : par exemple il emploie les mystérieuses unités h et w qui lui sont propres, basées sur le pixel ; en revanche il n’accepte pas l’unité em. Mais certaines qualités le sauvent : en théorie, l’attribut @srcset pourrait permettre au navigateur de choisir en fonction de la bande passante. Celui-ci pourrait alors prendre la décision la plus appropriée quant à la résolution qui convient le mieux, selon les réglages choisis par l’utilisateur et/ou en fonction des données collectées sur la vitesse de l’ensemble des requêtes.

Néanmoins, vue la façon dont sa spécification est rédigée, @srcset n’est rien de plus qu’un ensemble de suggestions que le navigateur peut choisir de suivre ou d’ignorer. L’auteur de ces lignes grince un peu des dents à l’idée de laisser un contrôle total au navigateur sur cette question, et j’imagine ne pas être le seul.
Est-ce qu’on ne pourrait pas trouver un juste milieu ?

Voyant les avantages de l’attribut @srcset, le Groupe Images Réactives a publié une proposition qu’il appelle « le Compromis de Florian », et qui associerait les atouts d’@srcset et de l’élément <picture>.

<picture alt="Un chat qui danse">
<source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
<source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
<source srcset="small-1.jpg 1x, small-2.jpg 2x">
<img src="small-1.jpg">
</picture>

Certes, la syntaxe de <picture> est plus verbeuse, mais elle reste très lisible et nous évite l’étrange raccourci syntaxique « 100w ». On peut imaginer que certaines choses évoluent à l’avenir, mais en attendant, de notre côté nous utilisons la solution Picturefill de Filament Group, qui est basée sur les div, que nous trouvons facile à utiliser et qui ne requiert pas d’architecture serveur ni de fichiers .htaccess. Elle se contente d’émuler l’élément <picture> comme s’il existait déjà.

Histoire d’aller fouiner sous le capot, notre démonstration précédente utilisait deux exemples originellement tirés de Picturefill pour modifier les sources selon la taille adoptée par le navigateur. J’ai effectué de petites modifications à notre démo, en combinant les deux sources @1× et @2× en une seule démo Picturefill écrite avec sa nouvelle syntaxe.

Technique expérimentale : le hack du 1.5×

Nous avons tenté une autre approche à Paravel : jouer sur les moyennes. Quelle que soit votre expérience, vous avez dû remarquer que les écrans à haute résolution se débrouillent fort bien quand il s’agit d’exploiter au mieux les pixels disponibles ; vous pouvez vous en rendre compte avec cette version expérimentale en @1.5× de notre démo :

Taille | Petit | Moyen | Grand
@1× | 37kb | 120kb | 406kb
@1.5× | 73kb | 248kb | 835kb
@2× | 120kb | 406kb | 1057kb

Si vous n’avez pas d’écran haute résolution, vous pouvez monter le zoom de votre navigateur à 200% pour simuler son rendu des différents niveaux de compression. L’image @1× offre de façon évidente la moins bonne fidélité sur les écrans haute résolution, tandis que l’image @2× a sans nul doute la meilleure. On voit néanmoins que la version @1.5× est presque aussi bonne que la @2×, tout en étant presque 20% plus légère. Que croyez-vous que vos visiteurs remarqueront en priorité, la différence de fidélité de l’image ou la vitesse de chargement de la page ?

Au bout du compte, la pertinence de la technique @1.5× dépend de la situation. Il est certain qu’elle pénalise l’utilisateur doté d’une configuration en @1×, mais vous trouverez peut-être qu’un @1.2× ou @1.3× constitue pour vous un meilleur compromis. Aujourd’hui, on peut considérer cette méthode du « prévoyez un poil plus grand » comme une solution viable pour gagner un peu de qualité sur des images d’importance moyenne, sans pour autant ajouter encore un niveau de complexité à nos clients. Dans les cas où vous ne pouvez pas faire de changements de fond, ce peut être une bonne façon d’améliorer le rendu sans (trop) alourdir la page.

Et surtout : utilisez votre cerveau

Récemment, alors que nous travaillions sur un nouveau design pour notre propre site à Paravel, nous avons appris à remettre en question nos propres règles. Comme nous comptons dans l’équipe l’illustrateur de talent qu’est Reagan Ray, notre site utilise beaucoup de SVG. Mais lorsque nous avons exporté notre image adorée des « Trois Amigos », nous avons réalisé un petit audit et nous nous sommes aperçus que la version SVG faisait 410kb. Comme nous trouvions ça lourd, nous avons exporté une version PNG plutôt grande en 2000x691, mais qui ne pesait plus que 84kb. Pas besoin d’être des Einstein de l’expérience utilisateur pour juger que nos visiteurs vont préférer des images qui se chargent cinq fois plus vite, par conséquent cette image sera en PNG.

Donc, utilisez votre cerveau. J’ai la légère impression que dans nos métiers, on ne le dit pas assez. Mais enfin, vous n’êtes pas idiots, c’est vous qui faites d’Internet ce qu’il est, et vous êtes bien capables de prendre de bonnes décisions. Regardez bien ce que vous faites, pesez le pour et le contre, et vérifiez tout le temps si vos idées préconçues s’avèrent pertinentes.

Et puis soyez souples. Dans ce métier, il n’y a pas de baguette magique pour tout résoudre : les positionnements en absolute, les méthodes, les processus de travail, tout cela peut se démoder d’une semaine à l’autre. Nous l’avons bien vu avec notre propre site : si on s’oblige à toujours appliquer des règles qu’on s’est imposé à nous-mêmes, ce ne sera pas forcément au bénéfice de nos utilisateurs.

Or, l’attention portée à l’utilisateur devrait rester primordiale pour le développement côté client — tout comme pour tout le reste de l’industrie du web, d’ailleurs. Certes, la densité des pixels peut évoluer dans tel ou tel sens, mais gardez en tête ce proverbe : ce qui est bon pour l’utilisateur est toujours bon pour les affaires.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : Mo’ Pixels Mo’ Problems
  • Auteur : Dave Rupert
  • Date de parution : 25 septembre 2012
  • Traduction : Frédéric Chotard
  • Relecture : Véronique Bouvier
  • Date de traduction : avril 2013
  • Thèmes : Web Mobile, Design


Pompage.net - CSS : on reprend tout à zéro !

Les coulisses d’un design

Par Douglas Bowman

Ceux qui ne sont ni designers ni artistes pourraient penser que les intéressés sont des prestidigitateurs, sortant de leur chapeau une création extraordinaire après l'autre. Le talent artistique et la créativité rendent certainement le résultat final plus beau, mais le design est généralement le résultat d'une méthode de travail. Chaque designer (ou groupe de designers) développe une méthode qui l'aide à résoudre des problèmes, puis améliore cette méthode au fil du temps. Bien qu'aucune personne ni aucun groupe n'aborde le même problème de la même manière, on constate souvent des similarités dans la démarche.

Comme je l'ai mentionné dans mon blog relatif à ma proposition pour le Jardin Zen CSS , j'ai pensé qu'il serait intéressant de partager avec vous le cheminement que j'ai suivi pour créer le design nommé Golden Mean. Créer une page pour le Jardin ne ressemble pas à un projet de taille normale, et ne ressemble en rien à un contrat avec un client exigeant , soumis notamment à des pénalités légales (retard, modification imprévue, etc.). Mais arrivé à mi-chemin, j'ai remarqué que j'avais la même approche (à une échelle quelque peu réduite) que sur un plus gros projet. On peut la décrire, pour le Jardin , par les étapes suivantes :

La recherche : découvrir le projet

S'atteler à un projet de maquette sans s'interroger sur la tâche à accomplir peut vous donner l'impression de partir vite, mais vous n'irez pas loin. Chaque projet, quelle que soit sa taille, tire profit de la recherche et de la planification effectuées en amont. Le design n'est pas une exception. L'observation avant l'action, voilà le secret pour trouver plus facilement la bonne direction à suivre. Le temps passé sur cette phase est habituellement proportionnel à la taille et à la durée prévue du projet.

Pour le design du Jardin , j'ai commencé par étudier le contenu (textuel) de la page, schématisant dans ma tête la structure et la hiérarchie du document. J'ai agrégé les différentes parties en groupes logiques et assigné à chacun une priorité. J'ai aussi pensé au but de ce projet, ainsi qu'aux idées et aux concepts que Dave Shea essayait de transmettre quand il a créé le Jardin et qu'il l'a ouvert à d'autres contributeurs. Montrer qu'on maîtrise les CSS n'est pas le but du projet. En revanche, il veut montrer la beauté et la flexibilité des CSS quand les designers comprennent leur potentiel, et les utilisent comme outils capables de créer une page bien agencée, esthétique, mais qui reste accessible, structurée, et codée avec efficacité.

L'analyse de la concurrence

Un autre travail utile est d'étudier les idées pré-existantes déjà mises en place par vos pairs, vos mentors, vos héros et/ou vos concurrents. Analyser la concurrence , c'est identifier les forces et les faiblesses des designs qui existent déjà. Cela vous permet de trouver quelles niches n'ont pas encore été explorées, et quels problèmes n'ont pas encore été réglés. La capacité à étudier ce qu'ont décidé les autres face au même problème (ou à un problème du même ordre) vous donne un avantage intéressant : on apprend beaucoup de leurs réussites et de leurs échecs.

Quand j'ai enfin eu un peu de temps pour penser à ma propre maquette, j'avais l'avantage de pouvoir étudier les propositions qui existaient déjà dans le Jardin . J'ai étudié le concept et l'exécution de chaque design. J'ai admiré l'intelligence et la créativité de certains de ces designs. J'ai noté leurs points communs et leurs différences. J'ai cherché ce qui n'avait pas été fait.

L'exploration

Face à un problème sans limites créatives, j'aime commencer par établir une liste de mots, de sujets, de phrases pertinents. Un genre de libre association d'idées sur le projet en cours. J'en trouve des abstraits comme j'en trouve des concrets, des vagues comme des précis. En écrivant ces listes, j'essaie d'acquérir une perspective d'ensemble du problème que je veux résoudre, et de faire sortir, souvent, des idées supplémentaires, des concepts qui n'étaient pas évidents a priori. Mes listes pour le Jardin comprenaient des mots et des pensées liés au jardinage, aux plantes et aux fleurs qu'on trouve dans un jardin, aux qualités associées au zen, à la beauté et aux belles choses, et à des caractéristiques de maquette de page. J'ai aussi établi une liste de tous les éléments, ID et classes utilisés dans le HTML de Dave, dont certains n'apparaissent que subtilement dans le design final.

Les croquis

croquis préliminaires Une fois que j'ai épuisé toutes les idées, j'ai commencé à dessiner des croquis sur un bloc de papier. Les croquis peuvent être de la taille d'un timbre, comme mesurer une dizaine de centimètres en largeur et/ou hauteur. Pensez aux gribouillis que vous pourriez voir sur une nappe en papier. Les croquis servent à capturer les idées de base de la composition de la page, comme l'emplacement de l'en-tête de page, la structure des colonnes, l'alignement des textes, sans être tenté de rentrer dans les détails si tôt dans le projet. Leur vitesse d'exécution vous permet une itération rapide. Vous n'aimez pas ce que vous avez fait en trente secondes ? Recommencez un dessin juste à côté. Pour rester général, il est mieux de commencer par de petits dessins. Ensuite, agrandissez-les progressivement au fur et à mesure que vous devez définir les détails.

La typographie

saisie d'écrans de différentes jeux de polices Une fois que j'ai eu quelques modèles de composition qui me plaisaient, j'ai commencé à réfléchir aux polices, à la forme des lettres. Pour moi la typographie est un élément crucial pour définir le niveau de formalité d'un design. Ce qu'évoquent des typographies différentes est subliminal pour la plupart des gens, mais un designer fera tout son possible pour que l'effet des différentes polices vienne asseoir l'esprit du design. La façon la plus facile de voir quel effet est associé à quelle police a été pour ce projet de créer un fichier Illustrator et d'écrire CSS Zen Garden et The Beauty of CSS Design de plusieurs manières. J'avais une idée de ce que je voulais obtenir. De plus, je suis assez familier avec de nombreuses polices. Mais je voulais explorer toutes les possibilités. Je voulais quelque chose qui caractériserait le design intelligent. Quelque chose d'amusant, ou d'unique, qui s'articulerait avec les idées que je commençais à avoir.

saisie d'écran de la police Morpheus J'ai choisi la police finale ( Morpheus ) pour ses très belles lettres. Les M et N sont très différents, les A et les U font des arches gothiques, les K et les R ont un jambage unique, les S et les d minuscules entre autres ressemblent tellement à des nombres, le point du i minuscule est un diamant décoratif qui rend plus gracieuses les rondeurs des D, O et Q. En plus de mon affinité avec la forme des lettres, le style médiéval prononcé du titre contrastait parfaitement avec la modernité du sans-serif utilisé pour les mots-clés des sous-titres en Helvetica .

Les images

Il n'est pas nécessaire d'avoir recours aux images pour un design. En fait, certains des plus beaux designs n'utilisent que de la typographie. Cependant, une photographie ou une illustration soigneusement sélectionnée peut avoir un impact énorme dans un design, en lui donnant une dimension, une implication, et un niveau de compréhension plus profond qu'un simple paragraphe d'introduction.

image utilisée pour la base du graphisme, © 2003 par Lee Pettet L'étape suivante a consisté à rechercher une image qui servirait autant de fondation à la texture de fond que de support visuel pour le contenu. La liste que j'avais établie précédemment dans la phase d' exploration me donnait une direction à suivre et faisait surgir de nouvelles idées. Après avoir fouillé dans mes propres cartons et dans des ressources externes d'images libres de droits, j'ai sélectionné différentes images qui comportaient déjà un peu de l'effet de couches que je voulais sur ma page. J'ai opté pour une image de marguerite (© 2003 par Lee Pettet) retouchée comme base graphique pour le Jardin .

Depuis longtemps, j'aime l'idée de faire des couches de texte les unes sur les autres pour apporter de la texture et du sens au design. J'aime combiner le texte et l'image, pour créer des variations subtiles de couleurs et de teintes (pour l'histoire, voyez dans mon CV : 01, 02, 03). Comme pour mes autres créations, j'ai construit la typographie du Jardin progressivement, au travers d'une série d'additions, de soustractions, et de manipulations.

La composition

J'ai tendance à confiner l'image dans une région particulière de la page, ou à la réserver à un but spécifique. Je pense qu'abuser de photographies ou d'illustrations peut surcharger un design et le rendre confus, ce qui obscurcit l'intention du message. J'aime travailler avec cet élément de design qu'est le contraste quand je crée une composition visuelle. Ce contraste s'exprime tant dans l'usage de l'image dans la composition que dans l'image elle-même. Intégrer efficacement une thématique visuelle dans un design demande d'être très conscient des équilibres et des tensions en jeu. Des zones compactes de mouvement et d'activité, contrebalancées par des espaces où l'oeil se repose.

mise en page presque définitive Avec mes quelques croquis et mes premiers choix de typograhie et d'images, j'ai commencé à monter des compositions plus développées. En jonglant d'Illustrator à Photoshop, en important des morceaux de l'un à l'autre, le design purement graphique s'approchait de la fin. Quand je travaille sans HTML et CSS, je me concentre sur la construction du langage et des lignes de force de la page, je trouve les proportions, largeurs et hauteurs, gouttières et espaces blancs, je spécifie les polices complémentaires, je choisis les tailles relatives des polices, leur interlignage, et comment appliquer la couleur pour appuyer mon propos à la fois en force et en subtilité.

L'exécution

J'ai déjà parlé de certains de mes problèmes quand j'ai écrit les CSS de ce design du Jardin (voir ma brève à ce sujet pour les détails). J'ai d'abord écrit les CSS qui définissaient la structure globale, les fonds principaux et les grandes régions de la page. Les groupes d'éléments se positionnaient à leur place. Puis j'ai appliqué le détail nécessaire à chaque élément, de haut en bas dans la page.

Pendant que j'écrivais la feuille de styles et que je la testais dans plusieurs navigateurs, le design a légèrement changé. J'ai dû sacrifier certains détails. J'en ai grandement amélioré certains autres. L'addition d'une trame de fond à gauche et à droite de l'image principale est le résultat positif du fait que je ne pouvais pas positionner l'en-tête de la page comme je l'imaginais à l'origine. L'alignement vertical n'a pas été définitif tant que chaque colonne n'était pas positionnée sur la page. (les colonnes de gauche et de droite étaient à l'origine à des hauteurs différentes).

Ces changements étaient possibles parce qu'en tant que designer et auteur de la feuille de styles, je pouvais décider au pied levé de ce qui devait être conservé, de ce qui pouvait être bousculé, et, surtout, de ma marge de manoeuvre au fur et à mesure que je codais. Cette unité de pensée en phase finale de réalisation met bien en évidence la nécessité pour le designer et l'intégrateur de collaborer le plus étroitement possible, s'ils ne sont pas déjà une seule et même personne.

Pour aller plus loin

Je me suis arrêté là pour ma proposition du Jardin Zen CSS , mais le travail de design est un processus en mouvement perpétuel. Ce résumé n'est pas exhaustif. On peut imaginer aussi plus de retours au designer, de plus longs circuits d'approbation, des tests utilisateurs. Le résultat n'en est pas toujours prévisible, ne vous attendez pas à une précision d'horloger. En tout cas, à moins qu'un designer ne travaille pour un illusioniste, le design n'est certainement pas un effet d'optique... De temps en temps, peut-être, un tour de passe-passe...

Fiche technique

  • Article original : A Design Process Revealed
  • Auteur : Douglas Bowman
  • Date de parution : 2 juin 2003
  • Traduction : Stéphane Deschamps
  • Date de traduction : octobre 2003
  • Thème : Design
  • Niveau : Tous niveaux

À propos de l'auteur

Fondateur et manager de Stopdesign, Douglas Bowman est un spécialiste du design simple, propre, et tourné vers l’avenir. Il repousse en permanence les limites du possible en matière d’utilisation des standards web. Douglas a été le grand architecte de la fameuse refonte de Wired News en 2003, mais il promet de ne pas se reposer sur ces lauriers pendant trop longtemps.


Pompage.net - CSS : on reprend tout à zéro !

Les colonnes factices

Par Dan Cederholm

Une des questions que l'on me pose le plus fréquemment à propos du design de mon site personnel est la suivante :

Comment faites-vous pour que la couleur d'arrière-plan de la colonne de droite s'étende jusqu'en bas de la page ?

En fait, l'idée est vraiment simple, c'est un concept que beaucoup parmi vous connaissent peut-être déjà. Pour les autres, la technique qui suit peut s'avérer une petite astuce bien pratique.

L'étirement vertical

Une des propriétés un peu frustrantes des CSS est le fait que, verticalement, les éléments s'étirent seulement aussi loin qu'ils en ont besoin. C'est à dire que si une image haute de 200 pixels est contenue dans un <div>, ce <div> s'étendra vers le bas de seulement 200 pixels.

Cela devient un dilemme intéressant quand vous utilisez l'élément <div> pour diviser votre balisage, puis appliquez la feuille de style pour créer une mise en page en colonnes. Une colonne peut être plus longue que l'autre (voir image 1). En fonction de la quantité de contenu imbriqué, il devient difficile de créer une mise en page avec deux grandes colonnes de tailles égales quand on veut une couleur d'arrière-plan unique pour chacune d'elles.

Image 1

Il y a plusieurs techniques pour que ces colonnes apparaissent de longueurs égales, indépendamment de leur contenu. Voici ma solution personnelle pour un cas précis (à utiliser avec une mise en page positionnée de façon absolue), qui est, en fait... hyper simple. Ce même petit truc est aussi utilisé ailleurs, entre autres par le site A List Apart (site de la publication originale, NdT).

La triche

Le secret, embarrassant de simplicité, est d'utiliser une image d'arrière-plan qui se répète verticalement pour créer l'illusion de colonnes en couleurs. Pour SimpleBits, mon image de fond ressemble à quelque chose comme l'image 2 (les proportions sont modifiées pour la démonstration), avec une bande décorative sur la gauche, une large section blanche pour la colonne du contenu, une bordure de 1 pixel, et une section en brun léger pour l'arrière-plan de la colonne de droite suivie par l'inverse de la bordure décorative du côté gauche.

Image 2 : image d'arrière-plan à étirer verticalement
Image 2

L'image entière n'est haute que de quelques pixels, mais quand elle est répétée verticalement cela crée les colonnes en couleur qui s'écouleront jusqu'au bas de la page, sans se soucier de la longueur du contenu des colonnes.

La feuille de style

Cette règle CSS élémentaire est ajoutée à l'élément body :

background: #ccc url(../images/bg_birch_800.gif) repeat-y 50% 0;

Avant tout, on déclare la couleur d'arrière-plan de la page entière comme gris et on répète l'image seulement sur la verticale (repeat-y). La partie 50% 0 renvoie au positionnement de l'image dans notre cas, à 50% du bord gauche de la fenêtre du navigateur (ce qui donne une image centrée) et à 0 pixels du bord supérieur.

Les colonnes positionnées.

Une fois l'image d'arrière-plan en place, ma mise en page se positionne au-dessus, avec un remplissage (padding) et des marges spécifiées pour les colonnes gauche et droite, ce qui permet de les placer au bon endroit à l'intérieur des fausses colonnes créées par l'image d'arrière-plan (voir Image 3).

Image 3

Il est important de noter que si on souhaite des bordures, des remplissages, et des marges sur l'une ou l'autre des colonnes, on devra faire du rafistolage pour IE/Windows à l'aide du modèle de boîte de Tantek Çelik. Voir le Box Model Hack ou le Mid Pass Filter.

D'un autre côté, si les attributs de bordures ou de remplissage peuvent être complètement évités en utilisant seulement des marges à la place, alors le hack du modèle de boîte ne sera pas nécessaire. Et si le contenu de la colonne se trouve (de façon transparente) au-dessus de l'arrière-plan répété, il doit être facile d'éviter le hack.

Le même en float

Bien que que j'utilise un positionnement absolu pour créer la mise en page sur deux colonnes de mon propre site, un résultat équivalent peut être obtenu avec la propriété float (comme vu sur ALA).

La même idée s'applique : répéter l'image d'arrière-plan, et poser une colonne flottante au-dessus des fausses colonnes ainsi créées.

Note finale

Le concept est simple, mais il peut alléger les frustrations que rencontrent fréquemment les designers en construisant des maquettes basées sur CSS.

Remerciements à Jeffrey Zeldman pour son aide à peaufiner cet article.

Cet article est sous le copyright du site A List Apart et de son auteur.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : Faux Columns
  • Auteur : Dan Cederholm
  • Date de parution : 9 janvier 2004
  • Traduction : Frédéric Valentin
  • Date de traduction : février 2005
  • Thème : CSS
  • Niveau : Tous niveaux

À propos de l'auteur

Designer, programmeur et bon vivant, Dan Cederholm a effectué aux standards web les re-designs de Fast Company et Inc.com. Il publie nouvelles et astuces sur le design depuis son site personnel, SimpleBits.

Article du même auteur

  • Arrière-plans cliquables


Pompage.net - CSS : on reprend tout à zéro !

Le DOCTYPE qu’il vous faut

Par Jeffrey Zeldman

Nouveau ! HTML5 arrive progressivement, et son doctype est bien plus simple à retenir : <!DOCTYPE html>. En le rencontrant, tous les navigateurs actuels passent en mode de rendu standard, vous pouvez donc l'utiliser dès aujourd'hui.

Vous avez fait tout ce qu'il fallait, mais votre site ne s'affiche et ne fonctionne pas comme il le devrait dans les derniers navigateurs.

Vous avez utilisé du XHTML valide et des CSS. Vous avez utilisé le Modèle d'Objet de Document (DOM) normalisé du W3C pour manipuler les éléments dynamiques de la page. Pourtant, dans certains navigateurs développés pour supporter ces normes, votre site ne fonctionne pas correctement. Un DOCTYPE fautif en est probablement la cause.

Ce bref article vous fournira des DOCTYPEs fonctionnels, et vous expliquera les effets pratiques, réels, de ces balises autrement très abstraites.

Pourquoi un DOCTYPE ?

Dans les normes du HTML et du XHTML, un DOCTYPE (contraction pour "Document Type Declaration") informe le validateur de la version de (X)HTML que vous utilisez, et doit apparaitre en première position dans chaque page web. Les DOCTYPEs sont des composants primordiaux pour les pages conformes aux normes : ni votre balisage ni vos CSS ne passeront une validation sans DOCTYPE.

Comme mentionné dans de précédents articles d'ALA (et dans d'autres endroits intéressants), les DOCTYPEs sont essentiels pour que les documents web s'affichent et fonctionnent correctement dans des navigateurs conformes aux normes, comme Mozilla, IE5/Mac, et IE6/Win.

Un DOCTYPE récent qui inclut une URI complète (une adresse web complète) commande à ces navigateurs d'afficher votre page en utilisant le "mode conforme" (NdT : "standard-complient mode" , vous pouvez retomber souvent sur le terme), traitant ainsi votre (X)HTML, CSS, et DOM de la manière que vous voulez.

Utiliser un DOCTYPE incomplet ou désaprouvé -voire aucun DOCTYPE- déclenche dans ces navigateurs le mode "Quirks" (NdT : "habitudes bizarres") qui va considérer votre balisage comme invalide et démodé, conforme seulement aux normes déprimantes de l'industrie de la fin des années 90.

Dans ce mode, le navigateur va essayer de traiter votre page en mode de rétro-compatibilité, affichant vos CSS comme IE4 aurait pu le faire, et retournant à un DOM propriétaire et spécifique au navigateur (IE retourne au DOM IE; Mozilla et Netscape 6 retournent vers Dieu sait quoi).

De toute évidence, ce n'est pas ce que vous voulez. Mais c'est souvent ce que vous aurez, à cause de la prépondérance des informations erronées ou incomplètes sur les DOCTYPEs, que cet article va s'efforcer de corriger.

(Note : Le navigateur Opera ne joue pas suivant ces règles ; il essaie toujours d'afficher les pages en mode conforme aux normes. Viva Opera ! D'un autre coté, il n'offre pas encore un support solide du DOM W3C. Mais c'est en passe de changer.)

Où sont passés tous les DOCTYPEs ?

Puisque que les DOCTYPEs sont vitaux au fonctionnement des standards web dans les navigateurs, et que le W3C en est le principal instigateur, vous pourriez vous attendre à ce que le site du W3C vous offre une liste des DOCTYPEs valides, et vous penseriez trouver cette information rapidement, facilement, et en un seul endroit. Mais à l'heure où nous écrivons ces lignes, ça n'est pas le cas.

w3.org n'est pas A List Apart, WebReference, ou Webmonkey. Son but n'est pas d'aider les designers web, les développeurs et les gestionnaires de contenu à se tenir au courant des dernières pratiques ou recommandations technologiques. Ce n'est pas son travail.

Le W3C publie une série de didacticiels, quoique la plupart des développeurs web l'ignorent. Mais le site du W3C héberge principalement une collection de Propositions, Documents de Travail et Recommendations, écrites pour des geeks par des geeks. Et lorsque je dis geek, je ne parle pas de professionnels du web comme vous et moi. Je parle de gens qui nous font ressembler à grand-mère la première fois qu'Elle a Eu un Message™.

Vous pouvez chercher des DOCTYPEs toute la journée sur w3.org sans trouver une seule page qui les énumère tous. Et lorsque vous arrivez enfin à en traquer un (généralement en relation avec une Recommendation ou un Document de Travail ), il ne fonctionne généralement pas sur votre site.

Éparpillés à travers le site du W3C, vous trouverez des DOCTYPEs sans URI et des DOCTYPEs avec des URIs relatives qui pointent sur le site du W3C lui-même. Utilisées sur votre page web, ces URIs pointeraient vers des documents non-existants, détruisant ainsi tous vos efforts et ceux du navigateur.

Par exemple, beaucoup de sites arborent fièrement ce DOCTYPE, copié-collé directement de w3.org :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "DTD/xhtml1-strict.dtd">

Si vous regardez la dernière partie du DOCTYPE ("DTD/xhtml1-strict.dtd"), vous verrez que c'est à l'origine un lien relatif vers un document se trouvant sur le site du W3C. Puisque ce document est sur leur site et non sur le vôtre, l'URI est inutile au navigateur.

Le DOCTYPE que vous devriez utiliser est en fait :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Notez que ce DOCTYPE inclut une URI complète en fin de balise. Puisque la balise pointe vers un emplacement valide sur le web, le navigateur sait où le trouver et affichera votre page en conformité avec les normes.

Des DOCTYPEs qui marchent

Alors quels DOCTYPEs devrions-nous utiliser ? Heureux que vous posiez la question. Les DOCTYPEs complets dont nous avons besoin sont les suivants :

HTML 4.01 Strict, Transitional, Frameset

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
       "http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
       "http://www.w3.org/TR/html4/loose.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
       "http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0 Strict, Transitional, Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPEhtml PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1 DTD

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
       "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Étapes suivantes

Comment pouvez-vous aider à améliorer le support des normes sur le web ? À part ajouter cette page à vos favoris (et recopier ces DOCTYPEs pour votre propre usage), si votre éditeur web insère des DOCTYPEs vous pouvez les vérifier et les comparer à ceux de cette liste.

Beaucoup de fabricants de logiciels bien intentionnés ont copié-collé dans leurs programmes des DOCTYPEs incomplets depuis le site du W3C. Résultat : lorsque vous utilisez l'option d'insertion de DOCTYPE de ces logiciels, le navigateur passe en mode "Quirks" et tout votre travail part en fumée.

Ça vaut le coup de contacter les gens qui fabriquent votre suite de dévelopement préférée, et de poliment leur faire part de ce problème pour correction dans la prochaine mise à jour (dans certains cas, vous pouvez modifier votre éditeur vous-même).

Bientôt sur vos écrans

Nous avons toutes les raisons de penser que le site du W3C affichera bientôt une liste de DOCTYPEs corrects et utilisables, ainsi que d'autres informations essentielles, le tout dans un endroit facile à trouver (NdT : cette liste existe désormais). D'ailleurs, Karl Dubost, Conformance Manager de l'équipe Quality Insurance du W3C, a contribué aux informations contenues dans ce petit article.

De même, dès que le site du Web Standard Project sera ré-ouvert (très prochainement), il comportera aussi cette information. (NdT : vous pouvez y trouver aujourd'hui des modèles de pages avec DOCTYPEs complets.

Mais des sites sont conçus et construits tous les jours, et vous avez besoin de cette information tout de suite -alors la voilà.

Joyeux développement, et bon affichage !

Nouveau ! HTML5 arrive progressivement, et son doctype est bien plus simple à retenir : <!DOCTYPE html>. En le rencontrant, tous les navigateurs actuels passent en mode de rendu standard, vous pouvez donc l'utiliser dès aujourd'hui.
Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : Fix Your Site With the Right DOCTYPE!
  • Auteur : Jeffrey Zeldman
  • Date de parution : 12 avril 2002
  • Traduction : Benjamin Debouté
  • Date de traduction : juillet 2003
  • Thème : Web design
  • Niveau : Intermédiaire


Pompage.net - CSS : on reprend tout à zéro !

La vengeance des menus déroulants

Par Patrick Griffiths et Dan Webb

Notre premier article sur les menus déroulants «Suckerfish dropdowns», publié sur A List Apart, a montré avec un certain succès qu'on pouvait mettre en œuvre des menus déroulants sur une base de CSS : ils se sont révélés légers, accessibles, et fonctionnaient dans Internet Explorer grâce à leur imitation de la pseudo-classe :hover.

Vous les avez aimés, les revoilà : ils sont plus accessibles, encore plus légers (seulement 12 lignes de Javascript), bénéficient d'une compatibilité accrue (ils fonctionnent sous Opera et Safari sans devoir utiliser le moindre hack) et peuvent avoir plusieurs niveaux de profondeur.

Menus déroulants à un niveau

Bon, on ne va pas tergiverser. Le HTML auquel on a affaire va ressembler à ceci :

<ul id="nav">
<li><a href="/traduction/deroulants#">Squaliformes</a>
    <ul>
        <li><a href="/traduction/deroulants#">Echinorhinidés</a></li>
        <li><a href="/traduction/deroulants#">Oxynotidés</a></li>
        <li><a href="/traduction/deroulants#">Squalidés</a></li>
    </ul>
</li>

<li><a href="/traduction/deroulants#">Orectolobiformes</a>
    <ul>
        <li><a href="/traduction/deroulants#">Parascylliidés</a></li>
        <li><a href="/traduction/deroulants#">Brachaeluridés</a></li>
        <li><a href="/traduction/deroulants#">Orectolobidés</a></li>
        <li><a href="/traduction/deroulants#">Stégostomatidés</a></li>
        <li><a href="/traduction/deroulants#">Hémiscylliidés</a></li>
    </ul>
</li>

<!-- etc. -->

</ul>

Voilà : une bonne vieille liste non numérotée, bien structurée.

Pour démarrer, nous avons besoin d'un style de base :

#nav, #nav ul {
padding: 0;
margin: 0;
list-style: none;
}

#nav a {
display: block;
width: 10em;
}

#nav li {
float: left;
width: 10em;
}

Remarquez qu'il vaut mieux indiquer une largeur (width) dans le sélecteur #nav li, sinon Opera va péter un câble. Rappelez-vous aussi que dès qu'on fait flotter des éléments, le contenu situé en-dessous du menu déroulant doit être dégagé (avec clear: left).

Bien sûr, il faut cacher les listes que l'on veut voir se dérouler, mais pour avoir une meilleure accessibilité on évitera d'utiliser display: none, qui dissimule des éléments à certains lecteurs d'écran (comme on peut fréquemment le constater dans les articles portant sur les remplacements d'images). Vous pensez peut-être qu'il y a mille façons de régler ce problème, mais après avoir expérimenté de façon exhaustive tout ce qui est width, height, margin, top ou clip à travers un grand nombre de navigateurs, la meilleure solution (pour ce qui est des listes à plusieurs niveaux, en tous cas) réside dans une manipulation de la propriété left.

Les spécifications CSS affirment que pour une boîte positionnée de façon absolue, les valeurs top, right, bottom et left doivent créer un décalage par rapport au bloc qui la contient. Malheureusement, Opera décide de décaler les boîtes positionnées en absolu par rapport à la page, ce qui explique pourquoi les premiers "Suckerfish Dropdowns" ne fonctionnaient pas sous Opera : ils s'appuyaient sur les propriétés top et left avec des longueurs explicites.

Donc, à la place de display: none, on utilise left: -999em pour expédier la liste déroulante hors de notre champ de vision, et ensuite left: auto (plutôt que left: 0) pour la ramener en position :

#nav li ul {
    position: absolute;
    width: 10em;
    left: -999em;
}

#nav li:hover ul {
    left: auto;
}

Le problème est entièrement réglé pour tous les navigateurs qui supportent la pseudo-classe :hover, mais pour Internet Explorer il va falloir balancer le Javascript "Suckerfish" :

sfHover = function() {
    var sfEls = document.getElementById("nav").getElementsByTagName("LI");
    for (var i=0; i<sfEls.length; i++) {
        sfEls[i].onmouseover=function() {
            this.className+=" sfhover";
        }
        sfEls[i].onmouseout=function() {
            this.className=this.className.replace(new RegExp(" sfhover\\b"), "");
        }
    }
}
if (window.attachEvent) window.attachEvent("onload", sfHover);

En gros, ce code va appliquer la classe "sfhover" aux items ("li") de la liste ("ul") nommée ("id") "nav", lorsque ces items sont survolés par la souris. Cette classe est ensuite retirée en utilisant une expression régulière lorsque la souris quitte la zone.

Donc, maintenant que les Suckerfish sont bourrés de nouvelles classes, l'étape suivante consiste simplement à répéter le sélecteur :hover avec les sélecteurs de classe "sfhover" :

#nav li:hover ul, #nav li.sfhover ul {
    left: auto;
}

Et voilà. Vous avez un beau menu déroulant à un niveau.

Menus déroulants à plusieurs niveaux

L'article d'origine sur les "Suckerfish Dropdowns" ne s'intéressait qu'aux menus déroulants à un niveau, mais en étendant un peu la logique de cascade, il s'avère tout à fait possible de créer également des menus déroulants à plusieurs niveaux en CSS. Et, contrairement au code Javascript "Suckerfish" d'origine, la fonction "sfhover" applique le comportement à tous les items ("li") descendant de "nav", pas seulement aux enfants directs : donc, les menus déroulants à plusieurs niveaux sont désormais tout à fait utilisables, même avec Internet Explorer.

Pour commencer, disons que nous avons affaire à une structure de liste avec davantage de niveaux, comme celle-ci :

<ul id="nav">

<li><a href="/traduction/deroulants#">Squaliformes</a>
    <ul>
        <li><a href="/traduction/deroulants#">Echinorhinidés</a>

            <ul>
            <li><a href="/traduction/deroulants#">Echinorhinus brucus</a></li>
            <li><a href="/traduction/deroulants#">Echinorhinus cookei</a></li>

            </ul>
        </li>
        <li><a href="/traduction/deroulants#">Oxynotidés</a>
            <ul>
            <li><a href="/traduction/deroulants#">Oxynotus paradoxus</a></li>
            <li><a href="/traduction/deroulants#">Oxynotus bruniensis</a></li>
            <li><a href="/traduction/deroulants#">Oxynotus caribbaeus</a></li>
            <li><a href="/traduction/deroulants#">Oxynotus centrina</a></li>
            <li><a href="/traduction/deroulants#">Oxynotus japonicus</a></li>

            </ul>
        </li>
        <li>
        <!-- etc. -->
        </li>

    </ul>
</li>

<li><a href="/traduction/deroulants#">Orectolobiformes</a>
    <!-- etc. -->
</li>

</ul>

Nous allons devoir rajouter quelques petites choses à la méthode originale. Tout d'abord, la liste de troisième niveau (dans notre exemple "Echinorhinus brucus", "Echinorhinus cookei", etc) doit se dérouler sur le côté de l'item de liste qui lui correspond (en l'occurence "Echinorhinidés"), il faut donc rajouter cette règle qui s'appliquera à tous les menus déroulants après le premier :

#nav li ul ul {
    margin: -1em 0 0 10em;
}

Comme on ne peut pas préciser explicitement le point de départ supérieur de nos boîtes en position absolue, elles se situeront sous la ligne de l'item de liste survolé, ce qui explique pourquoi le niveau de listes suivant doit être placé à -1em. Mais cela ne suffira pas à élever suffisamment les menus pour qu'ils arrivent au niveau de l'item de liste correspondant, parce que les hauteurs de ligne par défaut sont supérieures à 1em (souvent 1.2em), on doit donc rajouter un petit quelque chose à la règle initiale de l'élément ul :

#nav, #nav ul {
    padding: 0;
    margin: 0;
    list-style: none;
    line-height: 1;
}

À cause de l'effet de cascade qui veut que l'affichage de la liste de deuxième niveau révèle également celle du troisième niveau, il faut aussi cacher explicitement cette liste de troisième niveau (souvenez-vous que nous devons répéter la pseudo-classe :hover avec la classe .sfhover) :

#nav li:hover ul ul, #nav li.sfhover ul ul {
    left: -999em;
}

Bien sûr, on peut passer outre cette règle de façon à afficher lorsque l'item de liste correspondant sera survolé, en étendant le principe d'affichage du menu déroulant (qui donnait ceci, avec le menu à un seul niveau : #nav li:hover ul, #nav li.sfhover ul { left: auto; }) :

#nav li:hover ul, #nav li li:hover ul, #nav li.sfhover ul, #nav li li.sfhover ul {
    left: auto;
}

Et avec ça nous obtenons un solide menu déroulant à deux niveaux.

En suivant la même logique, vous pouvez fabriquer autant de niveaux de menus que vous le voulez :

Pour les menus déroulants à trois niveaux :

#nav li:hover ul ul, #nav li:hover ul ul ul, #nav li.sfhover ul ul, #nav li.sfhover ul ul ul {
    left: -999em;
}

#nav li:hover ul, #nav li li:hover ul, #nav li li li:hover ul, #nav li.sfhover ul, #nav li li.sfhover ul, #nav

li li li.sfhover ul {
    left: auto;
}

Et pour quatre niveaux, même si c'est peu probable...

#nav li:hover ul ul, #nav li:hover ul ul ul, #nav li:hover ul ul ul ul, #nav li.sfhover ul ul, #nav li.sfhover

ul ul ul, #nav li.sfhover ul ul ul ul {
    left: -999em;
}

#nav li:hover ul, #nav li li:hover ul, #nav li li li:hover ul, #nav li li li li:hover ul, #nav li.sfhover ul,

#nav li li.sfhover ul, #nav li li li.sfhover ul, #nav li li li li.sfhover ul {
    left: auto;
}

Exemples

À ce stade, vous avez peut-être déjà regardé les exemples très dépouillés à un, à deux, et à trois niveaux, ce qui est sans doute l'idéal pour observer le code source de la manière la plus claire et basique possible; mais bien entendu vous pouvez rendre tout ceci plus agréable à l'œil. Vous pouvez même en faire un menu vertical au lieu d'un horizontal.

Fiche technique

  • Article original : Son of Suckerfish Dropdowns
  • Auteur : Patrick Griffiths et Dan Webb
  • Date de parution : 18 mai 2004
  • Traduction : Frédéric Chotard
  • Date de traduction : février 2005
  • Thème : CSS
  • Niveau : Intermédiaire

À propos de l'auteur

Patrick Griffiths est un artisan du web basé à Londres qui possède un penchant pour la musique soul, l’évolution, et les promenades de son site de compagnie, HTML Dog. Selon son humeur, il peut préférer le surnom PTG.

Humble développeur web le jour, Dan Webb se transforme la nuit venue en invincible DJ. On ne sait pas ce qui lui demande le plus de pouvoirs, la mise en place de sites aux standards pour différentes instances gouvernementales britanniques, ou la mise à feu des boîtes de nuit londoniennes.

Articles du même auteur

  • Déclarations XHTML
  • Du stretching pour vos sites


Pompage.net - CSS : on reprend tout à zéro !

La cryptographie et le Web : hachage, salage et autres recettes

Par Lyle Mullican

L’un des outils de sécurité les plus puissants à disposition des développeurs web est la cryptographie, une opération consistant à transformer des informations porteuses de sens en bruit aléatoire, illisible sauf là où elles ont besoin d’être lues. Nombre de gouvernements ont strictement réglementé les logiciels de cryptographie jusqu’à une période relativement récente. Mais la cryptographie étant simplement des mathématiques appliquées, elle s’est avérée impossible à éliminer. Un développeur web qui travaille dans son garage sur son petit netbook a aujourd’hui accès à des cryptosystèmes majeurs dont les gouvernements rêvaient seulement il y a encore quelques décennies.

Il est tentant de croire qu’une simple application web n’a pas besoin d’une sécurité de niveau industriel parce qu’elle n’est pas censée contenir d’informations qui vaillent la peine d’être dérobées, telles que des numéros de carte de crédit. Malheureusement, les gens ont tendance à réutiliser les mêmes mots de passe sur les différents systèmes qu’ils emploient. Si le plus vulnérable de ces systèmes est compromis, l’accès aux autres sera généralement possible. En 2009, un pirate a ainsi fait parler de lui en réussissant à pénétrer dans plusieurs systèmes internes à Twitter après avoir piraté le compte e-mail d’un seul assistant administratif.

Tout artisan doit connaître ses outils et les matériaux pour atteindre l’excellence. Les développeurs web doivent quant à eux savoir quel type de cryptographie convient à quel contexte, même s’ils ne comprennent pas les opérations mathématiques utilisées dans leur moindre détail. Des méthodes de cryptographie mal appliquées n’apportent aucun avantage et peuvent même s’avérer dangereuses en procurant un faux sentiment de sécurité.
Il existe de nombreux types de cryptosystèmes, mais trois grandes catégories concernent habituellement les applications web.

Fonctions à sens unique

Il est impossible de partir d’une saucisse pour produire les ingrédients de base qui la composent. De même, une fonction de hachage cryptographique est conçue pour prendre des données et les mélanger afin que le résultat à l’autre bout soit irréversiblement méconnaissable. Décrite ainsi, cette opération ne semble pas particulièrement difficile ni utile. Mais les fonctions de hachage bien conçues présentent deux propriétés qui les rendent à la fois complexes et utiles.

Primo, une légère modification des données en entrée doit entraîner un changement drastique des données en sortie. Autrement dit, modifier un caractère des données hachées changera bien plus qu’un simple caractère en sortie. En règle générale, le hachage produit une empreinte de longueur définie (et relativement faible), quelle que soit la taille des données en entrée. Cela signifie qu’en théorie, plusieurs entrées peuvent donner le même résultat. Un pirate qui ne posséderait que l’empreinte cryptographique n’aurait donc pas la possibilité de remonter jusqu’aux données d’origine.

Secundo, une fonction de hachage produira toujours la même empreinte à partir de données identiques en entrée. L’application la plus évidente du hachage est le stockage des mots de passe. Une application web n’a pas besoin de réellement « connaitre » le mot de passe d’un utilisateur ; il lui suffit de vérifier que la personne demandant l’accès le connait. Si la même méthode de hachage est utilisée au moment de la création du mot de passe et au moment de l’identification, il suffit de stocker et de comparer uniquement le résultat des opérations de hachage pour savoir que les mots de passe originaux sont identiques. Ainsi, même si un pirate parvient à accéder à une base de données utilisateur, il n’obtient aucune information vraiment utile. En tout cas, c’est l’opinion la plus répandue.

Ce n’est pas si simple en réalité. Tout d’abord, tous les algorithmes de hachage ne naissent pas égaux. L’algorithme MD5 par exemple a connu son heure de gloire, mais est réputé aujourd’hui pour son manque de fiabilité général sur le plan cryptographique (bien qu’il puisse toujours être utilisé pour les mots de passe). Ensuite, nous savons que de nombreuses personnes choisissent les mêmes mots de passe courants. Un pirate qui connaîtrait la valeur de l’empreinte pour « 123456 » produite par quelques algorithmes couramment utilisés n’aurait aucun mal à la retrouver dans une base de données. Des listes d’empreintes précalculées, appelées tables arc-en-ciel (rainbow tables) par les professionnels de la sécurité, sont disponibles très facilement.

Afin de pallier ce point faible, une fonction de hachage peut être « salée ». Étant données les deux propriétés des bons algorithmes de hachage décrits précédemment, il suffit d’ajouter au mot de passe quelques données à notre sauce et de stocker l’empreinte de cette combinaison de textes plutôt que celle du mot de passe seul. Cette opération génère un résultat complètement différent, mais toujours facile à vérifier.

Comparez les deux exemples suivants :

sha1('mot_de_passe')
=> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

sha1('x5T1mot_de_passe')
=> e1f9530af9bde38db0eef386c4d22ec2ba10d2fe

Ici, ajouter quatre caractères aléatoires au début du mot change 95 % de l’empreinte.
Parmi les fonctions de hachage disponibles dans la plupart des langages de programmation, l’algorithme SHA-1, développé par la NSA [1], est à ce jour le plus efficace.

Chiffrement symétrique

Bien entendu, les fonctions à sens unique trouvent un usage assez restreint. La plupart du temps, les informations sont cryptées uniquement pour s’assurer qu’elles ne puissent pas être lues hors de leur contexte. Mais dans un contexte donné (une console d’administration, par exemple), le cryptage doit être réversible.

Toutefois, un développeur d’applications devrait toujours commencer par se poser la même question : « Ai-je vraiment besoin de recueillir et de stocker ces informations ? » Maintenir la collecte des données à un strict minimum simplifie le développement et contribue généralement à améliorer l’expérience utilisateur et bien entendu la sécurité. Après tout, les données qui n’existent pas ne peuvent être ni volées ni exploitées.

Mais si ces informations sensibles sont absolument indispensables à la fonctionnalité d’une application, il faut réfléchir à comment les manipuler en toute sécurité. Le cryptage réversible se divise en deux catégories. Dans la première, une seule « clé » secrète est utilisée pour chiffrer et déchiffrer les données. Les clés constituent une sorte de mot de passe, mais puisqu’elles sont utilisées plutôt par des programmes que par des humains, elles peuvent (et doivent) être plus longues et complètement aléatoires.

Avec les algorithmes modernes, le cryptage symétrique a l’avantage d’être extrêmement rapide. Le puissant algorithme AES (ou Rijndael) a été spécialement conçu pour être rapide et compatible, avec des implémentations à la fois dans les serveurs de bases de données et dans les frameworks applicatifs. Par exemple, crypter et décrypter des données dans MySQL est un jeu d’enfant :

INSERT INTO gens (nom_animal)
 VALUES (AES_ENCRYPT('Snoopy','ma-cle-secrete'));

SELECT AES_DECRYPT(nom_animal, 'ma-cle-secrete') AS nom_animal
 FROM gens;

Cette méthode n’empêche pas les informations d’être exposées si un utilisateur mal intentionné accède à l’application web, car elle sait comment décrypter les données. Cependant, elle empêche de divulguer accidentellement les données dans d’autres contextes, comme des fichiers de sauvegarde ou une attaque sur la base de données même.
Le cryptage symétrique fonctionne bien lorsque l’on accède toujours aux informations depuis le même contexte. Toutefois, sa force réside toute entière dans la clé secrète. Cela devient un problème lorsque les données ont besoin d’être transférées. La clé n’est plus secrète dès lors qu’elle est partagée, surtout avec plusieurs destinataires.

Chiffrement asymétrique

Pour répondre à ce besoin, les algorithmes asymétriques se basent sur une paire de clés générées avec certaines propriétés spécifiques. Lorsqu’un message est crypté avec une clé, seule l’autre clé correspondante peut le déchiffrer. Ce type de chiffrement est également appelé « cryptographie à clé publique », car il arrive souvent (mais pas toujours) que l’une des clés soit rendue publique et l’autre tenue secrète.

Il est intéressant de connaître les opérations mathématiques à la base de cette méthode, mais les développeurs web ont surtout besoin de comprendre quand utiliser ce type de chiffrement et la protection qu’il offre. Cette technologie est le plus fréquemment utilisée pour les connexions SSL (appelées TLS aujourd’hui). Le serveur web envoie sa clé publique au navigateur, qui l’utilise pour chiffrer les données que seul le serveur est capable de déchiffrer. Elle peut également servir à envoyer des e-mails chiffrés.

Comparées aux fonctions symétriques, les fonctions asymétriques sont lentes et nécessitent des clés beaucoup plus longues pour être efficaces. Dans le cadre de connexions TLS, le navigateur et le serveur utilisent simplement un système cryptographique à clé publique pour établir une clé symétrique temporaire afin de chiffrer les communications ultérieures.

Ces fonctions remplissent toutefois un rôle crucial dans la navigation web moderne. Elles nous permettent en effet de protéger les données qui transitent entre une application et les utilisateurs. La forte présence des réseaux Wi-Fi ouverts est une réelle source de préoccupation à ce sujet. Sur ces réseaux, les utilisateurs diffusent tout ce qu’ils font dans un rayon de 360° et sur une distance considérable. Non chiffrées, ces données peuvent être consultées facilement par n’importe qui équipé d’un ordinateur portable. En 2010, deux incidents très médiatisés ont mis ce risque en lumière. Tout d’abord, Google s’est trouvé aux prises avec les autorités chargées de la protection de la vie privée après avoir stocké accidentellement le trafic de réseaux Wi-Fi non chiffré capté par ses véhicules Street View. Ce que Google a fait accidentellement, d’autres peuvent le faire volontairement. Quelques mois plus tard, le plug-in Firesheep a fait les gros titres en montrant à quel point il est simple (et dangereux) d’espionner un réseau ouvert.

Les applications web devraient exiger au minimum des connexions TLS pour la transmission des informations d’identification. Il est encore mieux de les utiliser pour l’ensemble du trafic.

Comprendre le risque

Étant donnée l’utilisation que nous faisons des ordinateurs aujourd’hui, il est certain que toutes ces technologies seront de plus en plus importantes pour les développeurs web. Les événements de ces dernières années ont montré que ce risque n’était pas que théorique. Se dire que son application n’est pas assez réputée pour être ciblée ne suffit pas. Les attaques sont souvent automatisées, pas ciblées. Dans le même temps, nous devons comprendre et informer les gens des risques spécifiques qui existent et sur la manière d’utiliser la technologie pour les contrer. Sans cette démarche éducative, les clients peuvent considérer qu’un site ou une application est « sûre » tout simplement parce qu’elle accepte les connexions HTTPS. Sans comprendre pourquoi il est impossible de leur envoyer un mot de passe en clair dans un e-mail.

La sécurité n’est jamais absolue. Mais utilisée correctement, la cryptographie moderne nous fournit des outils pour éliminer les principales menaces. À nous de les mettre à profit.

[1] National Security Agency, agence de sécurité nationale américaine

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : Web Cryptography: Salted Hash and Other Tasty Dishes
  • Auteur : Lyle Mullican
  • Date de parution : 22 février 2011
  • Traduction : Blandine Proust
  • Date de traduction : février 2012
  • Thème : Technique
  • Niveau : Intermédiaire

À propos de l'auteur

Lyle Mullican est le vice-président de la société Operations for Corporate Web Services. Après des études d’art, il s’est passionné pour le design web sous toutes ses formes : architecture, code, présentation. Il écrit pour le blog de sa compagnie, son site personnel, et est présent sur les réseaux sociaux habituels.


Pompage.net - CSS : on reprend tout à zéro !

Formulaires : une méthode de validation qui a de l’avenir

Par Ryan Seddon

La validation des formulaires a toujours été une affaire délicate dès les débuts du web. D’abord, il y a eu les rapports d’erreurs de la validation côté serveur. Ensuite, on a évolué vers la validation côté client pour vérifier les résultats en ligne. Aujourd’hui, nous avons affaire au géant en marche que représentent les normes HTML5 et CSS3 : le chapitre sur les formulaires d’HTML5 propose de nouveaux types de saisies et de nouveaux attributs qui rendent possibles les contraintes de validation. Le module basique d’interface utilisateur de CSS3 fournit plusieurs pseudo-classes qui nous aident à appliquer des styles à ces états de validation et à modifier l’apparence d’un champ de saisie en fonction des actions de l’utilisateur. Voyons comment combiner les deux pour créer un validateur de formulaire basé sur les CSS et qui serait compatible avec un nombre suffisant de navigateurs.

Plus un utilisateur est guidé en temps réel lorsqu’il remplit un champ de formulaire, moins il risque de faire des erreurs. Regardez cet exemple de validation de formulaire en CSS3, dans un navigateur qui prend en charge les pseudo-classes UI de CSS3 (UI pour User Interface = Interface Utilisateur, NdT) comme Chrome 4+, Safari5+ ou encore Opera 9.6+. J’utilise des pseudo-classes UI de CSS3 et des attributs de formulaire en HTML5 pour effectuer une validation basée sur les CSS. Voyons comment tout cela fonctionne.

Les pseudo-classes UI de CSS3

Le module UI propose plusieurs pseudo-classes qui permettent d’appliquer un style aux champs de formulaires selon leur état. Leur sens en français est ici indiqués entre parenthèses.

  • valid (valide)
  • invalid (non valide)
  • required (obligatoire)
  • optional (facultatif)
  • in-range (dans les limites)
  • out-of-range (hors limites)
  • read-only (lecture seule)
  • read-write (lecture-écriture)

Dans la démonstration ci-dessus, j’emploie les pseudo-classes required, invalid et valid pour que la validation puisse se faire via la CSS :

input:focus:required:invalid {
  background: pink url(ico_validation.png) 379px 3px no-repeat;
}
input:required:valid {
  background-color: #fff;
  background-position: 379px -61px;
}

Puisque nous voulons attendre qu’un champ soit sélectionné avant de signaler qu’il est invalide, nous utilisons la pseudo-classe focus pour déclencher le style qui indique le caractère non valide de l’entrée. (Bien entendu, il serait peu judicieux en termes de design de marquer d’emblée comme non valides tous les champs restant à compléter).

Dès qu’un champ obligatoire non valide est sélectionné, le style déclenche l’apparition de l’image du point d’exclamation, qui signifie à l’utilisateur qu’il est nécessaire de remplir le champ. Une fois que les contraintes de validation de ce champ sont satisfaites, la pseudo-classe valid entre en action. On retire alors la pseudo-classe focus, afin que soit maintenue la coche verte qui indique un champ correct.

Les noms des pseudo-classes dont j’ai fait la liste plus haut sont explicites. Les pseudo-classes in-range et out-of-range sont à combiner avec les attributs min et max, qu’il s’agisse d’entrer une valeur par curseur, par saisie de nombre, ou pour tout autre type qui accepte ces attributs. Par exemple, si un utilisateur saisit une valeur qui sort des limites prévues (out-of-range), il est possible d’utiliser la pseudo-classe pour modifier le style afin de signaler cette situation ; on peut faire de même pour les valeurs qui sont bien dans les limites (in-range).

Pour le moment, seul Opera supporte les pseudo-classes in-range et out-of-range. D’autres navigateurs suivront rapidement.

De nouveaux types et attributs à notre disposition

Les formulaires HTML5 comportent désormais de nouveaux types d’entrées, tels que email, url et number. Par exemple, email ne déclenche la pseudo-classe valid que lorsque l’utilisateur saisit une adresse email valide ; le principe est le même pour number et pour url. Les contraintes de validation d’une URL varient selon les navigateurs. Sous Opera, il suffit de saisir « http:// » pour valider le champ de l’URL. Chrome réclame la saisie de « http://w », tandis que Safari n’exige que « http: ».

Il existe aussi quelques attributs qui peuvent faciliter la validation, comme placeholder, required, maxlength, pattern, min, max, et step :

<input id="code_postal" name="code_postal" type="number" min="1001" max="8000"
maxlength="4" required />

Le champ code_postal exploite le nouveau type number et certains des nouveaux attributs. En Australie, un code postal ne peut être composé que de quatre chiffres, donc j’indique cette limite avec l’attribut maxlength (= longueur maximale). Comme je veux aussi limiter la plage des nombres pouvant être saisis, j’utilise les attributs min et max pour fixer les limites. L’attribut required (= obligatoire) parle de lui-même.

Il est possible d’utiliser l’attribut step (= un pas) pour ajouter une contrainte en plus des indications de min et max. Par défaut, step est fixé à 1, ce qui permet de valider n’importe quel nombre situé entre les valeurs min et max, avec une incrémentation d’au moins 1. En passant step à 100, la validation ne se fera que si l’utilisateur saisit une valeur avec une incrémentation de 100. Par exemple, si je fixe à 100 la valeur de l’attribut step sur mon champ code_postal, 1001 sera une entrée valide, tout comme 1101, 1201, 1301, etc.

Trouver un modèle

Pour déclencher la pseudo-classe invalid dans des situations plus complexes, comme pour la saisie d’un numéro de téléphone rudimentaire, il est possible d’employer l’attribut pattern (= modèle) qui va nous permettre d’appliquer au champ une expression régulière.

<input type="tel" id="tel" name="tel" pattern="d{10}" placeholder=
"Veuillez saisir un numéro de téléphone à 10 chiffres" required />

L’expression régulière ci-dessus est assez simple. Elle énonce ceci : « Je n’accepterai qu’une saisie de dix chiffres exactement, et rien d’autre ». Ainsi, le champ restera non valide tant que les exigences de l’expression régulière ne sont pas satisfaites. Remarquez l’emploi de l’attribut placeholder pour donner une petite indication à l’utilisateur.

Les possibilités de l’attribut pattern peuvent aller plus loin encore, avec une expression régulière plus complexe, comme ici pour le champ mot_de_passe :

<input id="mot_de_passe" name="mot_de_passe" type="password" title="Au moins 8 caractères, un chiffre, une lettre majuscule et une minuscule" required
pattern="(?=^.{8,}$)((?=.*d)|(?=.*W+))(?![.n])(?=.*[A-Z])
(?=.*[a-z]).*" />

Puisque nous imposons des conditions spécifiques qui limitent ce que peut saisir l’utilisateur, l’obligeant ainsi à créer un mot de passe plus sûr, nous établissons une expression régulière complexe comme ci-dessus. Le mot de passe doit contenir au moins huit caractères, dont un chiffre, une lettre minuscule et une majuscule.

Afin d’aider l’utilisateur à remplir ces conditions, j’emploie l’attribut title pour l’aider à comprendre exactement en quoi elles consistent. J’évite ici d’utiliser placeholder car je dois donner un certain nombre d’explications, alors que placeholder ne doit être employé que pour de brèves indications.

Ajouter d’autres indications

Si l’utilisateur ne passe jamais son pointeur au-dessus des champs, mais se contente plutôt de passer de l’un à l’autre avec la touche Tab, il peut très bien ne jamais remarquer les instructions supplémentaires fournies par l’attribut title. Notez que sur les champs tel, code_postal et mot_de_passe, un message d’aide apparaît lorsqu’un champ exige des instructions complémentaires.

<input id="mot_de_passe" type="password"  /><p class="validation01">
  <span class="invalid">Au moins 8 caractères, un chiffre, une lettre majuscule et une minuscule</span>
  <span class="valid">Votre mot de passe remplit nos conditions, merci.
</span>
</p>

Le balisage ci-dessus intègre un conteneur supplémentaire qui contient à la fois les boîtes d’indications pour valid et pour invalid. Ainsi, quand l’utilisateur entre des données non valides dans le champ, l’information complémentaire vient l’aider. Mais quand il a saisi ce qu’il fallait, notre message ainsi que la petite coche verte le rassure en lui indiquant qu’il a rempli le champ correctement.

.validation01 {
  background: red;
  color: #fff;
  display: none;
  font-size: 12px;
  padding: 3px;
  position: absolute;
  right: -110px;
  text-align: center;
  top: 0;
  width: 100px;
}
input:focus + .validation01 {
  display: block;
}
input:focus:required:valid + .validation01 {
  background: green;
}
input:focus:required:valid + .validation01 .invalid {
  display: none;
}
input:focus:required:invalid + .validation01 .valid {
  display: none;
}

Pour montrer ou cacher le message d’aide selon l’état du champ, je peux cibler le champ en reliant les pseudo-classes grâce au combinateur-enfant adjacent qui ciblera l’indication adaptée. Une fois le champ correctement renseigné, le fond passe au vert et le message de validation apparaît.

L’approche actuelle et l’expérience utilisateur

On peut émettre un sérieux reproche vis-à-vis du fonctionnement de la pseudo-classe invalid, lorsque le remplissage d’un champ est requis et qu’il a des conditions supplémentaires à satisfaire : par exemple, quand on exige que le champ soit rempli ET que la saisie soit du type email. Dans la mesure où le champ restera non valide jusqu’à ce que les conditions soient remplies, il ira chercher les styles d’invalidité. Dans le cas présent, le champ se retrouverait non valide d’emblée et s’afficherait en rouge avec un message d’erreur avant même que l’utilisateur ait saisi quoi que ce soit. C’est pourquoi nous employons la pseudo-classe focus pour que les styles d’invalidité s’affichent uniquement quand un champ est sélectionné. Mais cette méthode n’est pas idéale, car si un utilisateur sort de ce champ sans avoir rempli les conditions de validation, le champ n’indiquera plus la présence d’un problème tant que l’utilisateur ne l’aura pas à nouveau sélectionné.

Une solution à ce problème consisterait à ajouter la pseudo-classe indeterminate qui est disponible avec les saisies de type bouton radio (radio) ou case à cocher (checkbox). Techniquement, cela signifie qu’un champ qui a d’autres conditions que son caractère obligatoire ne sera alors ni valide ni invalide, mais indéterminé. Cette idée réglerait la question de l’invalidité immédiate et nous permettrait d’appliquer un style au champ de façon optimale selon son état de validation.

Par ailleurs, nous pouvons appliquer des fonctions assez étendues sans employer de Javascript. Nous pouvons dire quel est l’état d’un champ, s’il est obligatoire, lui dire de se conformer à un certain schéma avec des expressions régulières, lui donner des valeurs maximales et minimales, et plus encore. Et si cela ne suffisait pas ? Et si on voulait aller plus loin ? Eh bien nous avons de la chance : le chapitre du HTML5 sur les formulaires propose aussi une spécification de l’API (API : interface de programmation, NdT) de contrainte de validation.

L’API de contrainte de validation

En plus de proposer tous ces nouveaux attributs, tous ces types de saisies et les pseudo-classes CSS3, le chapitre du HTML5 sur les formulaires spécifie une API JavaScript très simple qui va nous permettre de pousser plus loin les capacités de validation des formulaires, grâce à des méthodes, des attributs et des événements fort utiles qui y sont intégrés. Jetez un œil à la démonstration améliorée, qui exploite les possibilités de l’API de contrainte de validation.

Chaque champ de formulaire possède un nouvel attribut appelé validity. Cet attribut de validité renvoie un objet ValidityState qui représente le ou les état(s) de validité actuel(s) d’un élément. L’objet ValidityState contient plusieurs attributs booléens qui identifient l’état de validité dans lequel se trouve l’élément. Pour simplifier, il s’agit d’une série de réponses en vrai/faux qui indiquent au développeur ce qui ne va pas dans un champ donné :

  • valueMissing
    • Cet attribut renvoie true si un élément obligatoire est manquant.
  • typeMismatch
    • Cette valeur s’applique à tous les nouveaux attributs de saisie et signifie qu’il y a inadéquation entre la saisie et l’attribut type. Par exemple, si une valeur d’email est incorrecte, cet attribut renvoie true.
  • patternMismatch
    • Quand un élément contient l’attribut pattern et qu’il ne remplit pas les conditions régulières d’expression, cet attribut renvoie true.
  • tooLong
    • Quand un élément dépasse sa propriété maxlength (longueur maximale), cet attribut renvoie true.
  • rangeUnderflow et rangeOverflow
    • Si les attributs min ou max d’un élément sont supérieurs ou inférieurs aux valeurs indiquées, cet attribut renvoie true.
  • stepMismatch
    • Quand un élément doté de l’attribut step ne correspond pas à la valeur requise de l’incrémentation (step), cet attribut renvoie true.
  • valid
    • Si l’une des valeurs répertoriées ci-dessus renvoie un true, cet attribut renvoie alors false pour indiquer que le champ n’est pas valide. Sinon, lorsque toutes les conditions sont bien remplies, il renvoie true.

Et ce n’est pas fini...

L’événement invalid est un autre outil bien commode. Il est invoqué par le champ de saisie tant que celui-ci reste invalide. Nous pouvons donc y attacher un comportement et, dans notre cas, modifier le style du champ pour refléter son état actuel.

De plus, la méthode checkValidity() peut être exécutée soit sur un champ individuel, soit sur l’ensemble du formulaire, et elle renverra true ou false. L’exécution de cette méthode déclenchera aussi par voie de programme l’événement invalid pour tous les champs non valides (ou sur un seul élément si la méthode est exécutée sur un seul champ).

Je veux une démo

Reprenons notre démo précédente, afin de l’améliorer avec l’API de validation de contrainte. Grâce à ce que nous a appris Luke Wroblewski dans son article Inline Validation in Web Forms, et grâce à nos propres découvertes, nous sommes en mesure d’appliquer toutes ces idées à notre formulaire pour que l’expérience de validation en ligne soit optimale.

Premier élément que nous pouvons régler : l’application systématique du style « erreur » aux champs non valides. Au lieu d’appliquer immédiatement un style au champ pour indiquer à l’utilisateur qu’il ne remplit pas les conditions, on va plutôt attendre qu’il ait quitté le champ pour indiquer le problème.

Si les conditions sont satisfaites alors que le champ est toujours actif, nous informons instantanément l’utilisateur que le champ est correctement rempli. Pour cela, nous y attachons l’événement de saisie pour vérifier si le champ est valide. Dès qu’il l’est, nous mettons à jour les styles pour afficher immédiatement l’information.

Si un champ contient des valeurs incorrectes, et si l’utilisateur passe au suivant, l’événement blur (qui se produit lorsque l’élément perd le focus, NdT) va vérifier la validité du champ, puis appliquer les styles d’erreur pour informer l’utilisateur qu’il y a un problème. Ces styles resteront en place jusqu’à ce que les conditions soient remplies.

Et pour les navigateurs anciens ?

Toutes ces idées sont assez récentes, et la question de la compatibilité avec les navigateurs se pose : même si cette compatibilité est globalement bonne, il est irréaliste de penser qu’elle serait suffisante dans un environnement de production réel, qui doit prendre en compte les navigateurs plus anciens. C’est là que le script que j’ai écrit tombe à pic.

Pour les navigateurs qui ne prennent pas en charge le chapitre du HTML5 sur les formulaires et l’API de contrainte de validation, le script vient proposer une émulation de cette fonctionnalité. Pour les navigateurs qui sont compatibles avec ces éléments, le script le détecte et renvoie à la fonctionnalité d’origine. Jetez un œil à la démonstration qui a été mise à jour en y incorporant le nouveau script. Testez-la sous IE ou Firefox pour voir si cela fonctionne comme avec les navigateurs qui offrent un support natif.

Prise en charge par les navigateurs

Ce script a été testé avec succès dans les navigateurs suivants :

  • IE6+
  • Firefox 1+—FF4 offrira prochainement un support natif.
  • Chrome 4+—Support natif.
  • Safari 3.2+—Safari 5 dispose d’un support natif.
  • Opera 9.6+—Support natif.

Les fonctions suivantes sont émulées dans le script :

  • Chaque champ intègre l’objet validity qui fonctionne en arrière-plan et vous informe de l’état actuel du champ.
  • La méthode checkValidity() est disponible et indique si le formulaire, ou un élément spécifique, n’est pas valide.
  • Les attributs de saisie pattern, placeholder, required, min, max et step sont pris en charge.
  • Les attributs placeholder et required sont pris en charge pour les zones de texte.
  • L’attribut required est pris en charge pour les saisies de type select (listes à choix multiples, NdT).
  • Les types de saisie pour des valeurs d’email ou d’URL sont comparées à une expression régulière intégrée et resteront non valides jusqu’à ce qu’elles deviennent conformes.

Validation à gogo !

La prise en charge des formulaires HTML5 et du module CSS3 UI par les navigateurs commence à progresser. Opera 9 a montré le chemin en implémentant les formulaires Web 2.0 avant même qu’ils soient intégrés au chapitre du HTML5 sur les formulaires, mais ce navigateur ne supporte le module CSS3 UI qu’à partir de la version 9.6. Chrome est compatible depuis la version 4, Safari le fournit depuis peu dans sa version 5, Firefox doit l’ajouter dans sa prochaine version 4 (beta) ; et IE9, s’il continue à progresser dans ce sens, devrait aussi l’intégrer à l’une de ses prochaines versions.

Il est possible de réaliser de grandes choses avec les nouveaux modules et chapitres de CSS3 et d’HTML5. Au fur et à mesure que la prise en charge dans les navigateurs s’améliorera, ces types de techniques vont devenir des options viables qui pourront répondre aussi bien à une validation simple qu’à une validation complexe des formulaires.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : Forward Thinking Form Validation
  • Auteur : Ryan Seddon
  • Date de parution : 21 septembre 2010
  • Traduction : Frédéric Chotard
  • Relecture : Blandine Proust
  • Date de traduction : mars 2014
  • Thèmes : Ergonomie, CSS

À propos de l'auteur

Ryan Seddon (@ryanseddon) est un développeur frontend qui vit en Australie, à Melbourne. Il adore tripatouiller CSS et JavaScript et faire de nouvelles découvertes techniques. Vous pouvez les trouver, accompagnées d’autres articles, sur son blog : The CSS Ninja.


Pompage.net - CSS : on reprend tout à zéro !

Envoyons paître les mauvais navigateurs

Par Jeffrey Zeldman

Avec la mort des navigateurs de 4ème génération, cet article est plus ou moins obsolète aujourd'hui. Nous le conservons pour son intérêt historique : le début du mouvement pour exiger des fabricants de navigateurs qu'il fassent enfin des produits conformes aux standards.

Si l'apparence de ce site est relativement cohérente, félicitations ! Votre navigateur respecte bien, voire très bien les standards du web comme CSS-1, HTML 4.01, et les langages de scripts.

Si ce site est lisible mais aussi simple qu'un manteau amish, votre navigateur ne respecte pas les standards du web. Heureusement, vous pouvez facilement vous en procurer un qui le fasse.

Avant de commencer à hurler, peut-être que vous écouterez ce que nous avons à dire.

Qu'avez-vous fait ?

Nous avons mis à jour le design de A List Apart pour qu'il obéisse aux standards du web, certains d'entre eux (comme CSS-1) datant de 1996. Maintenant, bien sûr, nous sommes en l'an 2001.

Pourquoi est-ce que ça ne marche pas dans les vieux navigateurs ?

Ils n'ont pas été construits conformément aux standards. Le contenu de ce site sera accessible à tout navigateur, mais le design ne fonctionnera que dans les navigateurs supportant le CSS-1.

Pourquoi avez-vous fait cette chose horrible ?

Durant des années, l'idée d'un web accessible à tous ressemblait plus à un rêve de fumeurs d'opium qu'à la réalité. Puis en l'an 2000 Microsoft, Netscape et Opera ont commencé à livrer de bons produits. Enfin, nous pouvons récompenser leurs efforts en utilisant ces standards sur nos sites. Nous encourageons les autres à faire de même.

Pour ce faire, consultez la Browser Upgrade initiative du Web Standards Project pour conseils et soutien technique. Vous pouvez aussi agir de votre côté en validant votre balisage, et en informant courtoisement vos visiteurs de l'existence et de l'emplacement des navigateurs conformes. La Browser Upgrade initiative vous rend simplement la tâche plus aisée.

Baliser en accord avec ces standards ne veut pas nécessairement dire cesser de supporter les anciens navigateurs. Cela implique par contre de considérer attentivement ce qu'occasionne ce support. Si vous êtes délibérément en train de déformer votre balisage pour accommoder un pourcentage diminuant d'utilisateurs, et si cette déformation barre l'accès à d'autres utilisateurs (comme les personnes souffrant d'un handicap, ou ceux qui utilisent des Palm Pilots, Lynx, des lecteurs Braille ou tout autre dispositif Internet non-traditionnel), vous pourriez envisager d'augmenter votre respect des normes, même si le site résultant a l'air relativement ordinaire dans les vieux navigateurs. Si votre site est conforme et que le contenu est accessible à tous, vous avez probablement fait le bon choix.

Pourquoi maintenant ?

Cela fait des années qu'il y a des standards. Cela fait entre six mois et une année qu'il y a des navigateurs conformes. Si nous ne le faisons pas maintenant, alors quand ?

Il faut en moyenne 18 mois ou plus aux usagers du web pour mettre à jour leurs navigateurs. Beaucoup d'entre eux utilisent toujours des navigateurs qui datent de 1997, comme Netscape 4. Ces personnes ne feront de mise à jour que si nous leur donnons une raison pour le faire.

Si nous sommes assez nombreux à le faire, cette gestation de 18 mois peut être raccourcie, inaugurant ainsi un web construit sur des standards communs d'autant plus tôt. Cela nous paraît un objectif louable.

Vous pensez que votre mise en page à la noix vaut tout ça ?

Il ne s'agit pas de présentation visuelle. Il s'agit de la séparation du style et du contenu, qui nous permettra de faire des choses stupéfiantes. Comme refaire le design d'un site en quelques heures plutôt que quelques mois. Cesser de produire et déboguer du stupide balisage propre à chaque navigateur. Et supporter les navigateurs non-traditionnels, des Palm Pilots™ aux lecteurs Braille, sans construire des versions multiples de chaque page. Tout cela est plutôt bien.

Qui s'en soucie ?

Si vous êtes un web designer, vous. Dans six mois, un an, deux ans au plus, tous les sites seront construits avec ces standards. (Ou alors ils seront faits en Flash 7.) Nous pouvons regarder notre savoir-faire devenir obsolète, ou bien commencer à apprendre dès maintenant les techniques standard.

Etant donné les malheurs récents de l'économie du "dot-com", compter sur vos compétences actuelles pour assurer votre place de travail ne semble pas être un stratégie prometteuse. Apprendre à travailler avec les technologies émergentes est probablement un bien meilleur plan. Nous aimerions voir les lecteurs d'ALA rester employés durant les années à venir. Prendre garde à ces questions pourrait vous y aider.

Si ce n'est pas suffisant, considérez les nouvelles lois sur l'accessibilité du web. La séparation du style et du contenu avec HTML 4/XHTML et CSS peut vous aider à être en règle avec ces lois. Persister dans la voie des "hacks" et du bidouillage rend les questions de conformance bien plus difficiles. Temporairement, le revers de la médaille est que les sites conformes aux standards risquent de ne pas très bien marcher dans les navigateurs plus anciens. Mais les utilisateurs peuvent mettre à jour leur navigateur bien plus simplement que les personnes handicapées ne peuvent mettre à jour leur yeux, leurs oreilles ou leurs membres.

Est-ce que les navigateurs 4.0 peuvent lire votre feuille de style ?

Oui, mais ils la maltraitent tellement que nous avons utilisé une petite combine pour supprimer les styles dans ces navigateurs. A Designer's Journey explique comment nous l'avons fait.

Pourquoi ne pouvez-vous pas offrir la compatibilité avec les versions antérieures ?

Le vieux software n'est pas conforme aux standards. Ne l'avons-nous pas déjà mentionné ? Ce serait très cool si on pouvait avoir en même temps compatibilité avec les versions antérieures et pure conformité aux standards. Mais on ne peut pas. On doit choisir. Pendant des années, la plupart d'entre nous avons choisi la compatibilité avec les anciens navigateurs. Mais est-ce vraiment le meilleur choix ?

Depuis des années, on nous apprend à être de bons petits designers, construisant des sites qui fonctionnent dans des navigateurs qui ne fonctionnent pas. Chaque site que nous construisons selon la vieille méthode devient un tas de mauvais code en plus, une destination de plus sur le web qui cessera de fonctionner lorsque navigateurs et standards évolueront.

Plus on le fera longtemps, plus on verra proliférer de sites condamnés. Des milliers de sites sont lancés chaque jour. La plupart sont construits conformément aux mauvais navigateurs plutôt qu'aux standards. Assez. Nous avons enfin de bons navigateurs. Utilisons-les.

Poussons ces navigateurs vers leurs limites, découvrons les dernières lacunes dans leur conformance aux standards, et aidons les fabricants de navigateurs à les rendre encore plus conformes. Les gens qui utilisent Flash font ça. Ils poussent le Flash aussi fort que possible, se heurtent la tête contre ses limites, et disent à Macromedia comment l'améliorer. En conséquence, le Flash ne cesse de s'améliorer. Est-ce qu'on ne devrait pas faire la même chose pour les outils qui fournissent 90% du contenu et des fonctionnalités du web (i.e. les navigateurs) ? Le WaSP pense que oui et ALA également.

Mon employeur a "standardisé" un navigateur 4.0.

Nous sommes conscients qu'un grand nombre d'entre vous sont coincés dans cette situation. Considérez ceci comme une occasion pour attirer l'attention de votre supérieur ou de votre département IT sur le fait que les navigateurs cuvée 1997 sont en train de retarder le web. Faites-leur penser qu'une mise à jour était leur propre idée. Ça aide souvent.

Je n'ai pas les moyens pour un nouvel ordinateur, et ma vieille machine n'arrive pas à faire tourner ces navigateurs dernier cri.

Un navigateur conforme n'est pas nécessairement un veau. Beaucoup d'entre eux nécessitent moins de puissance de calcul que les navigateurs 4.0. On ne citera pas de noms, mais si vous consultez la page Browser Upgrades du WaSP, vous trouverez un ou plusieurs navigateurs qui tourneront tout à fait bien sur votre système existant.

On dira ce qu'on voudra, ces nouveaux navigateurs ne marcheront pas sur mon 286 avec 4MB de RAM.

Peut-être bien que non. Mais de nouveau, si nous accélérons l'adoption de standards communs sur le web, nous le rendrons plus accessible à tous - et nous encouragerons les fabricants de dispositifs Internet et de postes de travail à prix modeste à se conformer à ces mêmes standards dans leurs nouveaux produits financièrement abordables.

En attendant, ce site est conforme aux standards et fonctionne dans n'importe quel navigateur. Il est plus joli dans un navigateur conforme-CSS, mais le contenu est accessible pour n'importe quel navigateur ou dispositif d'accès. C'est aussi un design peu gourmand en bande passante (et encore moins maintenant que nous avons pu nous débarrasser de 6K de tableaux imbriqués), ce qui le rend plus sympathique encore pour ceux qui ont des connections lentes ou un équipement ancien.

Ce site fonctionnera avec n'importe quel dispositif capable de lire du HTML. On ne fait pas vraiment plus convivial que ça.

Le JavaScript, c'est mal !

Merci de partager vos sentiments. Désactivez le JavaScript si vous le voulez; le site fonctionnera toujours.

Pourquoi n'avoir pas utilisé le XHTML ?

Par paresse, et par nécessité de finir de refaire le site à temps pour le lancement du "Browser Upgrade" du WaSP. De plus, la dernière fois que nous avons vérifié, HTML 4.01 était un standard web valide.

Vous avez fumé la moquette, ou est-ce que vous vous attendez vraiment à ce que d'autres sites fassent ça ?

A quelle question aimeriez-vous que l'on réponde en premier ?

Vous vous attendez vraiment à ce que d'autres sites fassent ça ?

Eh bien, nous l'avons fait. Et Babble List, affiliée de longue date à ALA, vient de le faire aussi. De nombreux constructeurs de sites nous ont déjà dit leur intention de suivre le mouvement. Votre site sera-t-il le suivant ?

Vous seriez en bonne compagnie. De nombreux sites utilisent déjà abondamment les Feuilles de Style - entre autres CNN, ESPN, et Hewlett-Packard. Ces sites utilisent du code qui détermine quelle Feuille de Style est préférable pour votre navigateur, puis la charge dynamiquement. A la place, nous avons écrit une seule Feuille de Style qui fonctionnera dans n'importe quel navigateur supportant bien le CSS.

Nous reconnaissons que tous les sites ne peuvent pas faire ce changement maintenant, et nous ne nous attendons pas à ce qu'ils le fassent. Mais comme plus d'entre nous commenceront à le faire, d'autres suivront. Un homme avec une batte est un hooligan. Mille hommes avec des battes forment un régiment.

Pourquoi est-ce qu'un client sain d'esprit accepterait de faire cela ?

Pourquoi est-ce qu'un client sain d'esprit accepterait de dépenser un demi-million de dollars pour un site Flash sans même demander une version HTML ? Cela nous dépasse, mais nous pouvons citer une douzaine d'entreprises qui l'ont fait. Pourquoi est-ce qu'un client sain d'esprit donnerait son accord pour un site qui ne fonctionne que sur une plateforme ? On aimerait bien savoir, mais on l'a vu se produire, et vous également. Se conformer aux standards au prix d'une dégradation de l'expérience visuelle dans les anciens navigateurs nous paraît avoir plus de sens que l'une ou l'autre des pratiques que nous venons de mentionner.

Et n'oubliez pas, vous n'êtes pas limités aux clients sains d'esprit.

En fait, durant les dernières semaines, certains de nos clients les plus sains et les plus intelligents ont demandé ou été convaincus d'envisager des mises en page conformes aux standards qui séparent la présentation du contenu. Est-ce que chaque client voudra cela maintenant ? Probablement pas. C'est une question de besoin d'audience et d'objectifs. Mais partir du principe qu'aucun client ne le voudra est défaitiste et probablement faux. D'après notre expérience, généraliser au sujet de clients est aussi inutile que de généraliser au sujet de flocons de neige. Chaque client et chaque projet est différent.

Comment est-ce que vous l'avez fait ?

C'est marrant que vous le demandiez. Le deuxième volet de l'édition de cette semaine explique en détail comment nous avons fait la transition entre une mise en page basée sur les tableaux HTML et une construite avec deux DIV et une Feuille de Style. Vous trouverez peut-être ça utile.

Depuis que nous avons publié ce numéro, nous avons révisé nos feuilles de style une seconde fois, pour qu'elles fonctionnent effectivement mieux dans plus de navigateurs tout en nécessitant moins de "hacks" subtils et de bidouillages. Cette histoire-là est couverte dans les notes sur le numéro 100.

Vous pouvez aussi vous informer sur les standards ici à ALA (commencez avec les articles listés en marge), dans le département de resources du Web Standards Project, dans de chouettes publications comme Builder.com, Webmonkey, Webreference, XML.com, ou directement à la source.

Est-ce que vous êtes en train de dire que les tableaux HTML sont morts ?

Non. Il y a de bonnes et de mauvaises utilisations de tableaux HTML. Une bonne utilisation est de créer une page en plusieurs colonnes. ALA a réussi à faire une mise en page à deux colonnes sans tableaux, mais une mise en page à trois colonnes n'est pas particulièrement facile à obtenir avec le CSS seul, même si c'est prévu pour CSS-3. (Pour plus d'informations à ce sujet, voyez le deuxième article.) [Mise à jour: En fait, créer une mise en page liquide à trois colonnes en CSS-1 n'est pas vraiment aussi difficile que nous le croyions au départ. Mais nous garderons ça pour un autre article.]

Par contre, l'utilisation de tableaux imbriqués pour simuler une bordure de un pixel autour d'une zone, ou bien l'utilisation d'un tableau pour créer une couleur de fond derrière du texte ne sont plus nécessaires une fois que vous utilisez les Feuilles de Style. Et franchement, il est bien plus simple de taper <div class="menu"> que de passer votre vie à déboguer des tableaux HTML.

Vous avez essayé de mettre à jour un site de production comme Yahoo! ou Amazon en séparant le contenu de la présentation ?

On a été un peu occupés cette semaine. Mais David Eisenberg de ALA a tenté le coup. En deux heures, il avait partiellement converti Yahoo! Weather. Téléchargez le fichier zippé de Yahoo Weather si vous êtes intéressé, et ne dites pas que nous ne vous avons jamais rien donné.

Note à l'attention des litigieux: nous ne prétendons pas être associés avec Yahoo (nous ne somme pas associés avec Yahoo), et nous n'avons pas l'intention de bafouer les droits d'auteur ou les marques déposées. Le fichier zippé est simplement un exercice didactique, utilisant un site bien connu (et ravissant !) pour voir s'il peut être converti par des techniques de design conformes aux standards. Nous adorons Yahoo et pleurons d'admiration pour les juristes de Yahoo. Nous souhaitons aux juristes de Yahoo et à leurs familles mille ans de santé et de prospérité. Vous avez bien fait d'envoyer ces vilains messieurs dans le champ de maïs. [NdT: référence à un épisode de 'La quatrième dimension']

Deux heures, hein ? Et c'est toujours pas fini ?

Si vous sous-entendez que passer des méthodes de design "ancien style" aux nouvelles n'est pas toujours facile ou automatique, vous avez raison. C'est surtout le cas parce que peu d'entre nous comprenons vraiment profondément le CSS. Même ceux d'entre nous qui pensons le saisir sommes toujours en phase de rodage.

Pour la plupart d'entre nous, travailler avec des tableaux HTML est devenu une seconde nature, même si c'est une affaire de fous. Comprendre et manipuler le modèle de boîte CSS, et les techniques CSS sophistiquées comme Float, demande une dose d'apprentissage et un peu de patience. Cela aide aussi si vous abandonnez l'idée de dupliquer servilement une mise en page existante à base de tableaux, et laissez le CSS être du CSS. Par-dessus tout, soyez disposés à expérimenter, et ne maudissez pas ce qui est nouveau simplement parce que c'est différent.

Est-ce que vous avez entièrement reconstruit le site d'ALA ?

Pas encore. Si le site était construit dès le départ selon les standards, nous aurions pu le mettre tout entier à jour en éditant une seule Feuille de Style. Au lieu de ça, nous avons devant nous plus de 500 pages construites avec des tableaux HTML imbriqués et autres camelotes du genre. Nous sommes un site sans activité lucrative et avec un budget de zéro. On le fera dès qu'on pourra.

Z'êtes nuls, et vous venez de perdre un lecteur.

Nous sommes sincèrement désolés que vous ressentiez ça. Avant de partir, pourquoi ne pas partager vos sentiments dans le forum d'ALA ? Construit avec Cold Fusion, qui ne fait qu'un travail médiocre question conformance aux standards, il demeure par conséquent une portion de ce site que ne s'y plie pas. Vous adorerez l'interprétation qu'en fera votre navigateur 4.0.

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : To Hell With Bad Browsers
  • Auteur : Jeffrey Zeldman
  • Date de parution : 2001
  • Traduction : Stephanie Booth
  • Date de traduction : mars 2001
  • Niveau : Tous niveaux

À propos de l'auteur

Jeffrey Zeldman est le directeur créatif ainsi que le rédacteur en chef du site A List Apart.
Son dernier livre, Designing With Web Standards, s’impose déjà comme une référence en matière de web design.

Articles du même auteur

  • Le DOCTYPE qu’il vous faut
  • 99,9% des sites web sont obsolètes


Pompage.net - CSS : on reprend tout à zéro !

En route pour des composants HTML réutilisables

Par Niels Matthijs

Il y a quelques semaines, je suis retombé sur un vieil article que j’avais écrit pour Smashing Magazine, « Quand un mot en dit plus que mille ». Et si je défends toujours les principes de développement HTML que je citais à l’époque, je reconnais qu’il y manquait une chose importante : des exemples pratiques.

Bien entendu, la théorie derrière un code HTML élaboré à partir de composants est intéressante en elle-même mais, sans exemples, c’est plutôt abrupt et abstrait. Non pas que cela suffise à rebuter les passionnés du HTML – au contraire – mais il n’y a rien de mieux qu’un bon exemple pour clarifier les moindres détails d’un concept.

C’est donc ce que j’ai entrepris de faire dans cet article. Dans le précédent, j’avais présenté un assortiment de types de contenus qu’on retrouve fréquemment sur différents sites (comme des produits, des articles et des vidéos). Cette fois, je vais m’en tenir à quatre manières différentes de présenter un seul type de contenu : l’article (ou l’article d’actualité). C’est un type de contenu particulièrement courant et simple que beaucoup de personnes connaissent et auront à développer à différents moments dans leur carrière. Comme source d’inspiration concrète, je ferai référence au site internet du Boston Globe (un de mes préférés en terme de développement front-end).

Avant de commencer j’aimerais souligner un point important : le sujet de cet article ne concerne pas seulement le HTML obtenu mais la méthodologie pour écrire du HTML. Vous avez peut-être des points de vue différents sur le nommage des classes, les structures et l’ordonnancement du code source que je vais suggérer tout au long de l’article, mais ce n’est pas vraiment le sujet de l’article (même si je suis sûr que cela pourrait donner lieu à pas mal de discussions intéressantes).

La différence avec les autres méthodologies populaires basées sur des composants

L’utilisation de composants HTML n’est pas vraiment une nouveauté. Il y a quelques mois, Smashing Magazine a publié des articles sur BEM, OOCSS et SMACSS. Bien que je n’aie pas suffisamment d’informations pour juger BEM, les deux autres méthodologies sont clairement opposées à celle que je m’apprête à proposer ici.

Des méthodologies comme OOCSS et SMACSS sont nées de la frustration générée par CSS, mais ces méthodologies tentent de rendre le développement CSS plus simple en altérant le code HTML. Je pense que ce n’est pas du tout la voie à suivre (et si vous regardez la présentation initiale de Nicole Sullivan, vous verrez qu’elle propose une version anticipée des mixins comme meilleure alternative). Écrire du HTML ne consiste pas qu’à fournir les points d’attaches nécessaires pour implémenter le design : aborder les choses du point de vue des CSS diminue la qualité d’ensemble du HTML que vous écrivez. Le problème ne se limite pas à fournir le bon balisage pour CSS et JavaScript : le vrai défi est de s’assurer que chaque élément au sein d’un site web est identifiable. Si vous y parvenez, alors vous aurez couvert les besoins pour CSS, JavaScript et n’importe quelle autre technologie de script sans avoir à vous soucier des spécificités du projet.

La méthodologie que je vais vous présenter ici a été conçue dans une optique de réutilisabilité et de robustesse du code. Elle est largement indépendante des spécifications de chaque projet particulier et reste fidèle à la philosophie de pureté que le développement HTML doit respecter. Cela se traduit par de petits morceaux distincts de HTML qui sont aussi polyvalents que réutilisables.

Première étape : réunir toutes les vues et instances d’un même composant

Procédons par étape : premièrement, nous devons définir les pré requis de notre type de contenu. Pour faire cela, nous devons en principe prendre connaissance de toutes les maquettes du projet, lister et regrouper toutes les vues et différentes instances de chaque type de contenu. Pour que notre exemple reste aussi simple que possible, j’ai sélectionné quatre vues représentatives que j’ai trouvées sur le site web du Boston Globe.

Les actualités du Boston Globe

J’ai rapidement jeté un coup d’œil sous le capot et trouvé les marqueurs suivants dans le code HTML :

  • Vue avec liste réduite : .in-section ul li
  • Vue avec vignette : .vignette
  • Vue d’un résumé : div.resume
  • Vue détaillée : div.article (ou pas du tout d’élément racine)

Pour être honnête, je trouve cela assez compliqué. Si pour une raison quelconque vous vouliez isoler tous les articles de votre page ou de votre site web (que ce soit pour la CSS, des statistiques ou une autre raison), vous devriez contourner quelques ambiguïtés. Nous pouvons à coup sûr faire mieux.

Deuxième étape : définir la racine

<article class="recit">
   …
</article>

Et voilà ! Ce n’était pas trop difficile, n’est-ce pas ? Nous avons sélectionné l’élément article et lui avons affecté un nom de classe unique, que nous allons utiliser comme identifiant de base pour tous les articles. De cette manière, nous nous assurons que nous pouvons cibler tous les types d’articles en utilisant le même identifiant.

Comme vous pouvez le voir sur les exemples du Boston Globe, chaque vue nécessite d’être stylée de manière unique. En la reliant exclusivement au contexte des différents types d’articles c’est très loin d’être flexible, alors ajoutons une classe spécifique pour chaque vue :

  • Vue d’une liste réduite : .recit.liste-reduite
  • Vue d’une vignette : .recit.vignette
  • Vue d’un résumé : .recit.resume
  • Vue d’un article détaillé : .recit.detail

La raison qui nous pousse à ajouter des classes spécifiques à l’élément racine lui-même (plutôt que, par exemple, à une liste qui le contient) est la flexibilité. Si demain, on vous demande de construire une liste composite qui mélange des articles présentés à la fois sous forme de liste et sous forme de résumé, vous serez capable de le faire sans le moindre effort.

Troisième étape : définir des unités logiques internes

Maintenant que nous nous avons évacué ce problème, il est temps de nous pencher sur ce qu’il y a dans chaque composant article. Plutôt que d’écrire du HTML pour chaque vue séparément, nous allons commencer à examiner l’ensemble des vues, en listant tous les éléments (c’est-à-dire les unités logiques) que nous y trouvons. Pour chaque élément, nous allons définir le HTML correspondant. Pensez que ces unités logiques pourraient probablement réapparaître dans différents contextes et qu’elles sont habituellement des composants elles-mêmes, il y a donc de grandes chances pour que vous ayez déjà écrit des petits bouts de HTML pour celles-ci ailleurs dans votre projet.

Titre

Il y a toujours un titre. Le titre résume tous les contenus qui vont suivre, c’est donc une des parties les plus importantes de votre type de contenu (hormis le contenu lui-même, bien sûr). Toutes les vues répertoriées précédemment contiennent un titre, mais dans le cas où vous tomberiez sur une vue qui n’affiche pas un titre, insérez-le quand même dans le code HTML et masquez-le avec CSS, si nécessaire. De cette manière, vous allez toujours « entrer » votre type de contenu en sachant à quoi il fait référence. Et pour ce qui est du code, c’est relativement simple :

<h1>Titre d’actualité</h1>

Vignette

La seconde chose que nous voyons est une vignette image. Les vignettes images ne font pas vraiment partie du contenu, bien que dans de nombreux cas une vignette n’est rien de plus qu’une version redimensionnée (par le navigateur) de l’image initiale dans le contenu de l’article. Ce n’est pas forcément obligatoire, parce que la fonction d’une vignette est principalement d’être un repère visuel qui attire l’attention du visiteur sur l’article. Bien souvent, elle n’a même pas de lien logique avec l’article lui-même, donc considérons-la comme un élément autonome.

Encore une fois, le code est très simple. Nous avons juste ajouté un conteneur autour de l’élément img afin de pouvoir facilement ajouter une légende si nécessaire.

<div class="image vignette"><img src="…" alt="…" /></div>

Métadonnées

La plupart des types de contenu possèdent des métadonnées. Les métadonnées ne font pas vraiment partie du contenu lui-même, mais elles fournissent des renseignements supplémentaires sur le contenu inclus au sein des types de contenu. Dans les vues précédentes, nous trouvons plusieurs types de métadonnées : un auteur, une date de publication, un indicateur de section et une mention « Initialement publié dans [ressource] ».

C’est un peu plus délicat de trouver la bonne syntaxe pour une métadonnée. Si vous suivez la spécification HTML5 à la lettre, vous êtes censés utiliser une liste de définitions. Une métadonnée n’est rien d’autre qu’une liste de paires libéllé-valeur ce qui correspond exactement à ce que les auteurs de la spécification avaient en tête quand ils ont étendu la palette sémantique de la liste de définitions en HTML5. Mais puisque la syntaxe pour les listes de définition manque d’un conteneur pour les éléments de liste, ce n’est pas très robuste, et dans de nombreux cas, il s’avère vraiment difficile de les styler (même si ce n’est pas impossible). Vous pouvez rendre votre code invalide en entourant d’une div chaque paire « dd-dt » (afin de profiter des bénéfices sémantiques de l’élément), mais je préfère habituellement rendre mon code valide, quitte à sacrifier la sémantique de quelques balises au passage.

<div class="meta">
    <div class="auteur">
        <span class="dt">label:</span><span class="dd">valeur</span>
    </div>
    <div class="date-publication">
        <span class="dt">label:</span><span class="dd">valeur</span>
    </div>
    <div class="rubrique">
        <span class="dt">label:</span><span class="dd">valeur</span>
    </div>
    <div class="publie-dans">
        <span class="dt">label:</span><span class="dd">valeur</span>
    </div>
</div>

Extrait

Un extrait est un court résumé ou une introduction à votre type de contenu. Dans de nombreux cas, mais pas toujours, il est identique au texte d’introduction lui-même. Si l’extrait est semblable au texte introductif, vous pouvez considérer que c’est une partie du contenu actuel ; si c’est une copie adaptée, elle devrait être balisée séparément.

Comme pour le HTML, vous pourriez utiliser une balise de paragraphe avec une classe qui lui serait attachée, mais vous limiteriez ensuite les extraits à se rapporter à un paragraphe simple. Si l’on considère les exemples du Boston Globe, tout va bien, mais si vous voulez que votre code soit transférable à d’autres projets, il est sans doute plus sage de rester ouvert à d’autres options. Cela donne le code HTML suivant :

<div class="extrait">
    <p> … </p>
</div>

Liens d’actions

Dans la vue détaillée d’un article, nous voyons une liste d’actions relatives à l’article lui-même. Typiquement, les listes comme celles-ci incluent les actions d’impression et d’envoi par mail et, bien sûr, les options de partage sur les réseaux sociaux. Au lieu de les relier à la source ou à des classes numérotées, nous allons donner à chacune une classe unique de telle manière que nous puissions procéder à des variations si besoin.

<div class="actions">
   <ul>
      <li class="recommander">…</li>
      …
      <li class="imprimer">…</li>
   </ul>
</div>

Vous remarquerez que la liste d’actions est placée au-dessus du contenu, faisant d’elle une candidate parfaite pour être insérée à l’intérieur d’un élément header. Bien que je fasse cette concession au design, ces liens devraient se trouver dans l’élément footer de votre type de contenu. Ce sont des actions qui ne deviennent pertinentes qu’une fois qu’on connaît le contexte. Vous ne voudriez pas (ou au moins ne devriez pas) partager un article simplement basé sur le titre ; la connaissance du contenu est cruciale pour vous décider dans votre action. Les plus joueurs en CSS pourraient laisser de la place dans l’en-tête et y positionner la liste à partir du pied de page, mais cela rendrait l’implémentation CSS plus fragile.

Le véritable contenu

Finalement, nous en arrivons au point essentiel, l’article en lui-même. Ce qui se trouve à l’intérieur d’un article dépend souvent de la liberté que vous avez donné à votre éditeur de contenu. Soit vous lui avez donné un ensemble figé de modèles pour travailler, soit vous avez juste mis un éditeur WYSIWYG dans le CMS en gardant l’espoir que tout se passe au mieux. Une chose que vous devez faire cependant c’est englober la section de contenu, ne serait-ce que pour avertir que ce qui suit est du contenu généré par l’utilisateur.

<div class="contenu">
    …
</div>

Sujets apparentés

Finalement, nous trouvons une petite liste de sujets apparentés. La chose la plus importante à souligner ici est que cet exemple unique a exactement la même apparence que la liste des sujets apparentés que nous avons tenté d’établir auparavant, ainsi il n’y a réellement aucune raison de différencier le code HTML des deux exemples.

<section class="liste-articles">
    <div class="principal">
      <article class="article"> … </article>
    </div>
</section>

Quatrième étape : définir des conteneurs structurels

Les éléments listés ci-dessus constituent non seulement une suite logique d’éléments mais aussi une structure hiérarchique logique. Certains éléments précèdent le contenu lui-même et devraient être séparés du contenu principal. D’autres éléments sont des ajouts ou des informations supplémentaires et devraient être placés après le contenu. Pour réaliser cela, nous mettons en place une structure entête, corps, pied de page typique :

<article class="article">
   <header> … </header>
   <div class="principal"> … </div>
   <footer> … </footer>
<article>

Le conteneur principal n’apparaît pas forcément nécessaire à première vue mais, en tant qu’unité logique, il mérite son propre conteneur.

Cinquième étape : assembler le tout

Maintenant que tous les bouts de code HTML sont prêts, il est temps de tout rassembler pour créer un composant maître :

<article class="recit">
   <header>
      <h1>Titre d’article</h1>
      <div class="image vignette"><img src="…" alt="…" /></div>
      <div class="meta">
         <div class="auteur">
            <span class="dt">label:</span><span class="dd">valeur</span>
         </div>
         <div class="date-publication">
            <span class="dt">label:</span><span class="dd">valeur</span>
         </div>
         <div class="rubrique">
            <span class="dt">label:</span><span class="dd">valeur</span>
         </div>
         <div class="publie-dans">
            <span class="dt">label:</span><span class="dd">valeur</span>
         </div>
      </div>
      <div class="extrait">
         <p> … </p>
      </div>
      <div class="actions">
         <ul>
            <li class="recommander">…</li>
            …
            <li class="imprimer">…</li>
         </ul>
      </div>
   </header>
   <div class="principal">
      <div class="contenu"> … </div>
      <aside>
         <section class="liste-articles">
            <div class="principal">
               <article class="recit">…</article>
            </div>
         </section>
      </aside>
   </div>
   <footer> (utilisé pour les liens lire la suite, liens vers les commentaires, etc.) </footer>
<article>

Sixième étape : ajout des microdonnées

Bien que le code HTML soit maintenant flexible et suffisamment descriptif pour que d’autres scripts puissent extraire ou pointer n’importe quelle structure dont ils ont besoin, notre composant manque toujours d’un vocabulaire commun. Bien sûr nous avons ajouté une classe .recit à notre élément racine, mais si nous utilisions .actualite, .article ou .information ? Ils ne sont toujours pas très sémantiques.

Eh bien HTML5 met à notre disposition les microdonnées, une partie de la spécification HTML5 qui nous permet d’ajouter un vocabulaire global à notre code HTML. Vous pouvez créer votre propre vocabulaire si vous le désirez, mais si vous jetez un coup d’œil au site Schema.org vous vous apercevrez qu’il en existe plein pour les objets les plus courants.

La propriété itemscope doit être placée sur l’élément racine, de même qu’itemtype (qui spécifie une URL pour le vocabulaire — ici le site de Schema.org). Après il suffit de parcourir les propriétés des vocabulaires disponibles, et de les ajouter à votre code en utilisant itemprop. Nous obtenons alors le composant HTML suivant :

<article class="recit" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="fr" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">Titre d’actualité</h1>
      <div class="image vignette"><img src="…" alt="…" itemprop="image"/></div>
      <div class="meta">
         <div class="auteur">
            <span class="dt">label:</span><span class="dd" itemprop="author">valeur</span>
         </div>
         <div class="date-publication">
            <span class="dt">label:</span><span class="dd" itemprop="datePublished">valeur</span>
         </div>
         <div class="rubrique">
            <span class="dt">label:</span><span class="dd" itemprop="articleSection">valeur</span>
         </div>
         <div class="publie-dans">
            <span class="dt">label:</span><span class="dd">valeur</span>
         </div>
      </div>
      <div class="extrait" itemprop="description">
         <p> … </p>
      </div>
      <div class="actions">
         <ul>
            <li class="recommander">…</li>
            …
            <li class="imprimer">…</li>
         </ul>
      </div>
   </header>
   <div class="principal">
      <div class="contenu" itemprop="articleBody"> … </div>
      <aside>
         <section class="liste-articles">
            <div class="principal">
               <article class="recit" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">…</article>
            </div>
         </section>
      </aside>
   </div>
   <footer> (utilisé pour les liens annexes, liens vers les commentaires, etc.) </footer>
<article>

Septième étape : et pour terminer…

Maintenant que nous avons notre composant maître, il ne reste plus qu’à vérifier chaque vue et enlever les éléments inutiles du composant maître. Si cela se traduit par des restes de (= vides) conteneurs structurels, nous allons les supprimer aussi. Cela nous donne les bouts de code suivants :

Vue compacte

<article class="recit liste-reduite" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="fr" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">Titre d'actualité</h1>
   </header>
<article>

Vue d’une miniature

<article class="recit vignette" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="fr" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">Titre d'actualité</h1>
      <div class="image vignette"><img src="…" alt="…" itemprop="image"/></div>
      <div class="meta">
         <div class="rubrique">
            <span class="dt">label:</span><span class="dd" itemprop="articleSection">valeur</span>
         </div>
      </div>
   </header>
<article>

Vue compacte

<article class="recit resume" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="fr" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">Titre d'actualité</h1>
      <div class="image vignette"><img src="…" alt="…" itemprop="image"/></div>
      <div class="meta">
         <div class="auteur">
            <span class="dt">label:</span><span class="dd" itemprop="author">valeur</span>
         </div>
      </div>
      <div class="extrait" itemprop="description">
         <p> … </p>
      </div>
   </header>
   <div class="principal">
      <aside>
         <section class="liste-articles">
            <div class="principal">
               <article class="recit" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">…</article>
            </div>
         </section>
      </aside>
   </div>
<article>

Vue détaillée

<article class="recit detail" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="fr" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">Titre d'actualité</h1>
      <div class="meta">
         <div class="auteur">
            <span class="dt">label:</span><span class="dd" itemprop="author">valeur</span>
         </div>
         <div class="date-publication">
            <span class="dt">label:</span><span class="dd" itemprop="datePublished">valeur</span>
         </div>
         <div class="rubrique">
            <span class="dt">label:</span><span class="dd" itemprop="articleSection">valeur</span>
         </div>
         <div class="publie-dans">
            <span class="dt">label:</span><span class="dd">valeur</span>
         </div>
      </div>
      <div class="actions">
         <ul>
            <li class="recommander">…</li>
            …
            <li class="imprimer">…</li>
         </ul>
      </div>
   </header>
   <div class="principal">
      <div class="contenu" itemprop="articleBody">…</div>
   </div>
<article>

Les composants HTML réutilisables font sens

Si vous regardez de très près les principes au cœur du HTML, vous verrez que HTML ne laisse que peu de place pour les variations. Le code HTML que nous écrivons est censé décrire nos contenus aussi précisément que possible, indépendamment du style, donc il n’y a vraiment aucune raison de créer différentes versions de structures pour un seul composant qui apparaît dans plusieurs contextes, pages ou même des projets. Un article d’actualité est un article d’actualité, et bien que les parties internes puissent varier, la structure de base, la sélection de balise et les conventions de nommage ne doivent pas en pâtir. Bien sûr, il y a toujours de la place pour la personnalité de l’auteur, y compris pour des préférences personnelles mineures, certains principes et l’expérience en général, mais un auteur devrait idéalement s’en tenir à une structure unique pour un seul composant.

Le HTML basé sur des composants a également d’importants avantages pratiques. Bien entendu, l’article d’actualité ci-dessus n’est qu’un exemple basique, mais nous pourrions faire de même avec tous les composants utilisés sur nos différents projets. Cela peut sembler beaucoup de travail à première vue, mais vous n’aurez besoin de le faire qu’une seule fois ; après ça, vous pourrez utiliser le temps que vous avez gagné sur la partie ingrate pour améliorer votre bibliothèque de composants. Désormais le HTML que j’écris pour un nouveau site web est issu de 80 à 85% de composants prêts à l’emploi, les 15 à 20% restants sont de petits ajustements spécifiques au projet ou de nouveaux composants (qui pourront toujours faire partie de la bibliothèque plus tard). Cela fait gagner énormément de temps lors du développement du HTML.

C’est aussi un énorme avantage pour les personnes qui préfèrent concevoir dans le navigateur. Un des inconvénients majeurs de la conception dans le navigateur, c’est que le code HTML est généralement le cadet de vos soucis. Vous vous dites peut-être que vous pourrez toujours le nettoyer plus tard, mais si vous êtes honnête avec vous-même, vous savez que la probabilité que vous preniez le temps de parfaire un aspect de votre travail qui est la plupart du temps invisible pour le client est proche de zéro. En utilisant votre propre bibliothèque de composants, vous n’aurez plus besoin de vous préoccuper du HTML. Si vous avez besoin d’un composant, vous n’avez qu’à vous servir, en sachant que dès le départ votre HTML est de qualité, vous pouvez vous concentrer sur la conception et les CSS.

L’avantage le plus important du HTML basé sur des composants est la qualité de service que vous allez offrir à vos clients. Plutôt que de livrer des modèles spécifiques — des styles — à un projet, vous pouvez leur offrir une structure de composants HTML robustes. De cette manière vous laissez la possibilité à vos clients de déployer ces composants sur différents sites web. Encore une fois, cela va grandement accélérer le développement HTML (et l’implémentation dans le back-end) pour les futurs projets — projets qui peuvent maintenant démarrer dès que les gabarits sont terminés, sans avoir à attendre les éléments graphiques du design. On pourrait même pousser le bouchon plus loin et utiliser les composants HTML dans les wireframes (rattachés à un CSS en marque blanche). Les possibilités sont infinies. Par la même occasion, cette méthodologie amène un niveau de cohérence et de prévisibilité sans précédent dans le code de l’ensemble des sites du client, deux choses qui font souvent défaut ces jours-ci.

Le futur de HTML

Pour moi, un code HTML basé sur des composants réutilisables est la voie à suivre, et il est temps pour nous de passer ce cap dans notre développement HTML. Partez des composants que vous avez déjà construits, faites-vous une bibliothèque avec quelques bouts de code réutilisable et continuez à partir de là. Bien entendu, il y aura toujours besoin d’un certain niveau de personnalisation, mais je suis convaincu que les bouts de code de HTML ci-dessus peuvent être utilisés dans 90% des cas pour les différents types d’articles qu’on trouve sur le web. Les métadonnées changeront parfois un peu, la présentation nécessitera de modifier l’ordre des balises mais lles bases sont là pour créer tout ce dont vous aurez besoin en moins de cinq minutes. Il s’agit ici d’appliquer le principe de duplication (DRY) non plus à l’échelle d’un seul projet mais de plusieurs, et même d’un client à l’autre.

Au final, des méthodologies comme OOCSS et SMACSS vont à l’encontre de cet idéal, car elle sont liées aux styles visuels et empêchent la réutilisation correcte des composants sur différents sites web. Par conséquent elles vont aussi ralentir le cycle de développement car le design devient alors une dépendance de plus. Pour le moment, cela veut dire qu’il va falloir vous reposer sur des pré-processeurs CSS si vous voulez une CSS maintenable, néanmoins, à terme, tout le monde trouvera largement son compte en adoptant la méthodologie décrite ci-dessus. Je suis intéressé par vos retours sur ce point.

Fiche technique

  • Article original : The Road To Reusable HTML Components
  • Auteur : Niels Matthijs
  • Date de parution : 23 octobre 2012
  • Traduction : Frank Taillandier, Véronique Bouvier
  • Relecture : Goulven Champenois
  • Date de traduction : février 2014
  • Thèmes : HTML, Intégration, Workflow

À propos de l'auteur

Pour s’aider à supporter l’insoutenable pression que représente son blog, Niels vit dans le luxe. Le reste du temps, il travaille pour Internet Architects où il s’investit pour rendre le Web plus accessible et plus agréable.


Pompage.net - CSS : on reprend tout à zéro !

Au tableau !

Par Roger Johansson

L'utilisation des tableaux semble embrouiller les personnes qui débutent dans la mise en page basée sur les feuilles de styles. Dans beaucoup de cas, les gens traduisent « évitez d'utiliser les tableaux à des fins de présentation » par « n'utilisez pas de tableaux ». Il est important de savoir que les tableaux sont très pratiques, s'ils sont utilisés correctement.

Bien sûr, mieux vaut éviter d'utiliser les tableaux à des fins de mise en page, mais pour les données tabulaires, c'est ce qu'il faut employer. J'aimerais vous parler de la façon d'utiliser les tableaux pour mettre en forme des données tabulaires. En HTML et en XHTML, les tableaux sont plus que de simples lignes et cellules. Beaucoup plus. Surtout si vous désirez les rendre accessibles.

Tout d'abord, quelques informations de base. Vous pouvez trouver la recommandation « évitez d'utiliser les tableaux à des fins de présentation » dans l'introduction aux tableaux de la spécification HTML 4.01 :

Les tableaux ne devraient pas représenter simplement un moyen de disposer le contenu d'un document car cela peut entraîner des problèmes de restitution sur les médias non-visuels. En outre, quand on les utilise avec des graphiques, ces tableaux peuvent forcer l'utilisateur à effectuer un défilement horizontal pour voir un tableau qui aura été conçu sur un système avec une surface d'affichage plus grande. Afin de minimiser ces problèmes, les auteurs devraient employer des feuilles de style pour le contrôle de la disposition plutôt que des tableaux.

Ceci me semble clair, bien que le verbe utilisé est devraient et non doivent, ce qui rend la spécification assez souple à ce sujet.

Mais le propos de cet article n'est pas de discuter du bien-fondé de l'utilisation de tableaux à des fins de présentation. L'objectif est de traiter de l'utilisation des tableaux dans leur but originel : mettre en forme des données tabulaires.

Lorsque les tableaux sont utilisés pour mettre en forme des données, ce ne sont pas simplement des grilles servant à la mise en page. Les personnes voyantes peuvent facilement discerner les en-têtes des cellules de données en regardant la mise en page et la présentation visuelle du tableau. Les personnes aveugles ou fortement malvoyantes ne le peuvent pas. Pour permettre à un tableau d'être accessible aux personnes utilisant un lecteur d'écran ou tout autre logiciel de rendu non visuel, il faut expliquer au logiciel comment les différentes informations contenues dans ce tableau sont associées.

Pour cela, le langage HTML propose heureusement de nombreux éléments et attributs. En revanche, il est assez difficile de comprendre l'utilisation qu'on peut faire de ces caractéristiques destinées à l'accessibilité. Dans cet article, je vais essayer d'expliquer comment utiliser quelques-unes de ces possibilités.

Les en-têtes de tableaux, <th>

Commençons par un tableau très simple qui n'aurait qu'une seule ligne d'en-têtes, chacun d'eux définissant les données contenues dans les colonnes. Avec une mise en page à l'ancienne, contenant uniquement des lignes et des cellules, le balisage ressemblerait à ceci :

<table>
<tr>
<td>Entreprise</td>
<td>Employés</td>

<td>Fondée en</td>
</tr>
<tr>
<td>ACME Inc</td>
<td>1000</td>

<td>1947</td>
</tr>
<tr>
<td>XYZ Corp</td>
<td>2000</td>

<td>1973</td>
</tr>
</table>

Sans aucun style ni bordure, le tableau ressemble à cela dans votre navigateur :

Entreprise | Employés | Fondée en
ACME Inc | 1000 | 1947
XYZ Corp | 2000 | 1973

En appliquant quelques styles au tableau, vous pouvez mettre en évidence les en-têtes pour ceux qui utilisent un navigateur graphique :

Entreprise | Employés | Fondée en
ACME Inc | 1000 | 1947
XYZ Corp | 2000 | 1973

Pour une personne voyante, il est maintenant rapide et facile de faire le lien entre les en-têtes et les cellules de données qu'ils décrivent. En revanche, l'utilisateur d'un lecteur d'écran entendrait quelque chose comme Entreprise Employés Fondée en ACME Inc. 1000 1947 XYZ Corp 2000 1073. Pas vraiment facile de donner un sens à toutes ces informations.

La première — et la plus facile — des étapes à effectuer pour rendre ce tableau plus accessible est d'identifier correctement les en-têtes. C'est très simple : il suffit d'utiliser la balise <th> (table header, ou en-tête de tableau) au lieu de <td> (table data, donnée tabulaire) pour les cellules qui servent d'en-têtes :

<table>

<tr>
<th>Entreprise</th>
<th>Employés</th>
<th>Fondée en</th>

</tr>
<tr>
<td>ACME Inc</td>
<td>1000</td>
<td>1947</td>

</tr>
<tr>
<td>XYZ Corp</td>
<td>2000</td>
<td>1973</td>

</tr>
</table>

Entreprise | Employés | Fondée en
ACME Inc | 1000 | 1947
XYZ Corp | 2000 | 1973

Dans ce tableau simple, il y a suffisamment d'informations pour qu'un lecteur d'écran soit capable de faire comprendre à l'utilisateur quel en-tête est en relation avec quelles cellules. Un lecteur d'écran prononcera Entreprise : ACME Inc. Employés : 1000. Fondée en : 1947., et ainsi de suite pour chaque ligne. C'est bien mieux qu'avant.

Les légendes de tableaux : <caption>

L'élément <caption> peut être utilisé pour fournir une courte description du tableau, un peu comme la légende d'une image. Par défaut, la plupart des navigateurs graphiques affichent l'élément <caption> centré au-dessus de la table. Si nécessaire, cela peut-être changé à l'aide de la propriété CSS caption-side. La majorité des navigateurs afficheront la légende soit au dessus (caption-side: top), soit en dessous (caption-side: bottom) du contenu du tableau, tandis que d'autres accepteront gauche (caption-side: left) et droite (caption-side: right) comme valeurs. Je vous laisse le soin de tester cela par vous-même.

Lorsqu'il est utilisé, l'élément <caption> doit être placé juste après la balise ouvrante <table> :

<table>
<caption>Tableau 1 : données de l'entreprise</caption>

<tr>
<th>Entreprise</th>
<th>Employés</th>
<th>Fondée en</th>

</tr>
<tr>
<td>ACME Inc</td>
<td>1000</td>
<td>1947</td>

</tr>
<tr>
<td>XYZ Corp</td>
<td>2000</td>
<td>1973</td>

</tr>
</table>

Tableau 1 : données de l'entreprise
Entreprise | Employés | Fondée en
ACME Inc | 1000 | 1947
XYZ Corp | 2000 | 1973

Vous pouvez évidemment utiliser les styles pour modifier l'apparence de la légende, si vous le désirez. Cependant, il faut parfois faire preuve d'un peu de ruse pour modifier l'apparence de façon uniforme, quel que soit le navigateur utilisé. C'est un autre exercice que je vous laisse.

Pour expliquer les tableaux : l'attribut summary

Une personne voyante peut facilement décider de lire un tableau en détail ou pas. Un rapide coup d'oeil lui indiquera la taille du tableau, et ce qu'il contient globalement. Une personne utilisant un lecteur d'écran ne peut pas faire de même, à moins d'ajouter l'attribut summary à notre tableau. De cette façon vous pouvez fournir une description du tableau plus détaillée qu'en utilisant simplement l'élément <caption>, qui peut se révéler trop synthétique.

Le contenu de l'attribut summary ne sera pas interprété par les navigateurs visuels, donc n'hésitez pas à fournir une description assez longue pour que tous ceux qui l'entendent comprennent de quoi il s'agit. N'en faites pas trop non plus, et n'utilisez l'attribut summary que lorsque c'est vraiment nécessaire, par exemple pour des tableaux plus complexes dans lesquels un résumé facilitera la compréhension du tableau à une personne utilisant un lecteur d'écran.

<table summary="Le nombre d'employés et la date de création de quelques entreprises fictives.">

<caption>Tableau 1 : données de l'entreprise</caption>
<tr>
<th>Entreprise</th>
<th>Employés</th>

<th>Fondée en</th>
</tr>
<tr>
<td>ACME Inc</td>
<td>1000</td>

<td>1947</td>
</tr>
<tr>
<td>XYZ Corp</td>
<td>2000</td>

<td>1973</td>
</tr>
</table>

Pour raccourcir les en-têtes : l'attribut abbr

Lorsqu'un lecteur d'écran rencontre un tableau, il peut prononcer le ou les en-têtes associés avant chaque cellule de données. Si vous avez de longs en-têtes, les entendre à chaque nouvelle ligne peut devenir pénible. En recourant à l'attribut abbr pour abréger chaque en-tête trop long, vous permettez aux utilisateurs d'un lecteur d'écran d'utiliser ces abréviations en lieu et place de l'en-tête lui-même. L'utilisation de abbr est optionnel, et de toute façon vos en-têtes seront (ou devraient être) assez courts.

En modifiant légèrement notre tableau d'exemple pour rallonger les en-têtes, l'attribut abbr pourrait être utilisé comme suit :

<table summary="Le nombre d'employés et l'année de création de quelques entreprises imaginaires.">
<caption>Tableau 1 : données de l'entreprise</caption>
<tr>

<th abbr="Entreprise">Nom de l'entreprise</th>
<th abbr="Employés">Nombre d'employés</th>
<th abbr="Fondée en">Année de création</th>
</tr>

<tr>
<td>ACME Inc</td>
<td>1000</td>
<td>1947</td>

</tr>
<tr>
<td>XYZ Corp</td>
<td>2000</td>
<td>1973</td>

</tr>
</table>

Tableau 1 : données de l'entreprise
Nom de l'entreprise | Nombre d'employés | Année de création
ACME Inc | 1000 | 1947
XYZ Corp | 2000 | 1973

Un lecteur d'écran pourrait alors lire l'en-tête complet pour la première ligne de données, puis l'abréger dans les lignes suivantes.

Au vu de la difficulté à faire tenir des tableaux de données dans une mise en page, je dirais qu'il est plus simple de faire le contraire : raccourcir autant que possible les en-têtes, voire les abréger, et utiliser l'attribut title ou l'élément <abbr> afin de fournir une explication plus fournie.

Pour lier les en-têtes aux données : les attributs scope, id et headers

Beaucoup de tableaux sont plus complexes que celui que j'ai utilisé en guise d'exemple. Je vais le compliquer un peu en enlevant l'en-tête "Entreprise" et en transformant les cellules de données de la première colonne en cellules d'en-tête :

<table summary="Le nombre d'employés et l'année de création de quelques entreprises imaginaires.">
<caption>Tableau 1 : données de l'entreprise</caption>
<tr>
<td></td>
<th>Employés</th>

<th>Fondée en</th>
</tr>
<tr>
<th>ACME Inc</th>
<td>1000</td>

<td>1947</td>
</tr>
<tr>
<th>XYZ Corp</th>
<td>2000</td>

<td>1973</td>
</tr>
</table>

Tableau 1 : données de l'entreprise
 | Employés | Fondée en
ACME Inc | 1000 | 1947
XYZ Corp | 2000 | 1973

À présent, chaque cellule possède deux en-têtes. La méthode la plus simple et la plus propre pour s'assurer que les navigateurs non-visuels peuvent comprendre le sens de ce tableau est d'ajouter l'attribut scope à toutes les cellules d'en-tête :

<table summary="Le nombre d'employés et l'année de création de quelques entreprises imaginaires.">
<caption>Tableau 1 : données de l'entreprise</caption>
<tr>

<td></td>
<th scope="col">Employees</th>
<th scope="col">Founded</th>
</tr>

<tr>
<th scope="row">ACME Inc</th>
<td>1000</td>
<td>1947</td>

</tr>
<tr>
<th scope="row">XYZ Corp</th>
<td>2000</td>
<td>1973</td>

</tr>
</table>

L'attribut scope indique si la cellule d'en-tête fournit des informations d'en-tête pour une colonne ou pour une ligne :

  • scope: col : informations d'en-tête pour la colonne dans laquelle se trouve la cellule
  • scope: row : informations d'en-tête pour la ligne dans laquelle se trouve la cellule

Ajouter un attribut scope avec la valeur col aux en-têtes de la première ligne indique que ces derniers servent d'en-têtes aux cellules qui se trouvent en dessous. De même, assigner aux en-têtes de chaque début de ligne l'attribut scope avec la valeur row les transforment en en-têtes pour toutes les cellules se trouvant à leur droite.

L'attribut scope accepte en outre deux valeurs supplémentaires :

  • scope: colgroup : informations d'en-tête pour l'ensemble de colonnes prédéfini dans lequel la cellule se trouve
  • scope: rowgroup : informations d'en-tête pour l'ensemble de rangées prédéfini dans lequel la cellule se trouve

Un groupe de colonnes est défini par l'élément <colgroup>. Les groupes de lignes sont quant à eux définis par les éléments <thead>, <tfoot> et <tbody>. Je reviendrai sur ces derniers dans un instant.

Comment faire si vous voulez garder l'en-tête "Entreprise", et définir en même temps les noms d'entreprises en tant qu'en-têtes de ligne ? Les cellules contenant les noms d'entreprises fourniraient alors à la fois les informations d'en-tête et de données. Dans ce cas, <td> devrait être utilisé avec l'attribut scope :

<table summary="Le nombre d'employés et l'année de création de quelques entreprises imaginaires.">
<caption>Tableau 1 : données de l'entreprise</caption>

<tr>
<th scope="col">Entreprise</th>
<th scope="col">Employés</th>
<th scope="col">Fondée en</th>

</tr>
<tr>
<td scope="row">ACME Inc</td>
<td>1000</td>
<td>1947</td>

</tr>
<tr>
<td scope="row">XYZ Corp</td>
<td>2000</td>
<td>1973</td>

</tr>
</table>

De cette façon, les navigateurs visuels n'afficheront pas le nom des entreprises en tant qu'en-tête par défaut. Il faut donc faire un peu de CSS pour corriger ce problème. Pour cet exemple, j'ai utilisé le style suivant :

td[scope] {
    font-weight:bold;
}

Notez que cette règle utilise un sélecteur d'attribut, chose qu'Internet Explorer ne comprend pas. Pour contourner le problème, on pourrait ajouter une classe à chaque cellule de données afin de lui attribuer un style d'en-tête.

Tableau 1 : données de l'entreprise
Entreprise | Employés | Fondée
ACME Inc | 1000 | 1947
XYZ Corp | 2000 | 1973

Une autre technique pour connecter les données d'un tableau aux en-têtes correspondants consiste à donner un id unique à chaque en-tête. Un attribut d'en-tête (header) est alors ajouté à chaque cellule de données. Cet attribut contient une liste d'id, séparés par des espaces, de chaque cellule d'en-tête s'appliquant à cette cellule de données. Cette technique est plus compliquée, et ne devrait être utilisée que lorsque des cellules de données ont besoin d'être reliées à plus de deux cellules d'en-têtes, et que l'attribut scope est insuffisant, comme par exemple dans un tableau très complexe ou très irrégulier.

Pour illustrer mon propos, j'ai changé le tableau afin d'afficher le nombre d'employés de chaque sexe pour chaque entreprise :

<table class="extbl" summary="Le nombre d'employés et l'année de création de quelques entreprises imaginaires.">
<caption>Tableau 1 : données de l'entreprise</caption>
<tr>
<td rowspan="2"></td>
<th id="employes" colspan="2">Employés</th>
<th id="fondee" rowspan="2">Fondée en</th>
</tr>
<tr>
<th id="hommes">Hommes</th>
<th id="femmes">Femmes</th>

</tr>
<tr>
<th id="acme">ACME Inc</th>
<td headers="acme employes hommes">700</td>
<td headers="acme employes femmes">300</td>
<td headers="acme fondee">1947</td>
</tr>
<tr>
<th id="xyz">XYZ Corp</th>
<td headers="xyz employes hommes">1200</td>

<td headers="xyz employes femmes">800</td>
<td headers="xyz fondee">1973</td>
</tr>
</table>

Tableau 1 : données de l'entreprise
 | Employés |  | Fondée en
 | Hommes | Femmes
ACME Inc | 700 | 300 | 1947
XYZ Corp | 1200 | 800 | 1973

Comme vous le voyez, cette méthode devient très vite compliquée, et c'est pour cela que je vous conseille l'attribut scope autant que possible.

Étendre les lignes et les colonnes sur plusieurs cellules

À l'époque où on utilisait les tableaux pour mettre en page un site Internet, les attributs rowspan et colspan étaient très souvent employés pour étendre les cellules d'un tableau sur plusieurs lignes ou plusieurs colonnes dans le but de rassembler correctement une interface coupée en morceaux.

Ces attributs sont encore utilisés à l'heure actuelle, car il n'y a aucune façon de spécifier l'extension de cellules en CSS. Si on y réfléchit, c'est assez logique : l'extension de lignes et de colonnes fait partie de la structure d'un tableau, pas de sa présentation.

Colonnes et groupes de colonnes : <col> et <colgroup>

En HTML, les éléments <col> et <colgroup> servent à grouper des colonnes qui ont un rapport entre elles. Ceci permet (dans certains navigateurs) l'utilisation de CSS pour affecter un style aux colonnes de façon indépendante. Les groupes de colonnes peuvent aussi être utilisés par l'attribut scope pour spécifier qu'une cellule sert d'en-tête au reste du groupe de colonnes qui la contient.

C'est tout ce que je vous dirai concernant les colonnes et les groupes de colonnes. Pour plus d'informations, allez consulter les liens présents dans la section Ce que je ne vous ai pas dit.

Les groupes de lignes : <thead>, <tfoot> et <tbody>

Les lignes d'un tableau peuvent être regroupées dans un en-tête de tableau (<thead>), un pied de tableau (<tfoot>), et un ou plusieurs corps de tableau (<tbody>). Chaque groupe de lignes doit contenir une ou plusieurs lignes.

Si un tableau possède un en-tête, celui-ci doit apparaître avant le corps et le pied de tableau. Un pied de tableau doit apparaître uniquement avant le(s) corps du tableau. Si aucun en-tête ou pied n'est utilisé, l'élément <tbody> est inutile (mais pas interdit, vous pouvez donc l'utiliser si bon vous semble). La structure d'un tableau contenant des groupes de lignes ressemble à ceci :

<table>
<thead>
<tr></tr>
    ... quelques lignes pour l'en-tête de tableau

</thead>
<tfoot>
<tr></tr>
    ... quelques lignes pour le pied de tableau
</tfoot>

<tbody>
<tr></tr>
... quelques lignes pour le premier corps du tableau
</tbody>
<tbody>

<tr></tr>
... quelques lignes pour le deuxième corps du tableau
</tbody>
... quelques corps de tableaux supplémentaires si nécessaire
</table>

Le groupement de lignes peut être utile pour plusieurs raisons :

  • Il est plus facile de changer le style des différentes sections (en-tête, corps ou pied) d'un tableau de façon indépendante, sans avoir à ajouter de classe à chaque élément.
  • Lorsqu'un long tableau est imprimé, certains navigateurs (comme ceux basés sur Mozilla) répéteront les informations d'en-tête et de pied de tableau sur chaque page, rendant la lecture du tableau plus aisée.
  • Isoler le corps du tableau permet également aux navigateurs de le faire défiler indépendamment de son en-tête et de son pied.

Uniquement pour les tableaux contenant des données !

Tout ce qui a été décrit dans cet article est relatif à l'utilisation de tableaux HTML pour structurer et présenter des données. Si vous utilisez encore les tableaux à des fins de présentation, aucune des techniques citées précédemment ne devrait être appliquée. Pas d'attribut summary, pas d'en-tête, pas d'élément <caption>, rien. Seule une bête mise en page en tableaux, uniquement constituée des éléments <table>, <tr> et <td>. Dans le cas contraire, vous risqueriez d'augmenter encore la confusion de vos visiteurs !

Les bénéfices

Il peut sembler très éprouvant de créer des tableaux de données accessibles en HTML. Pour les tableaux complexes, c'est effectivement le cas. Parfois, il semble même impossible de les réaliser à la main. Pourtant, pour des tableaux simples, l'utilisation de cellules d'en-têtes avec un attribut scope est simple et rapide.

Il est évident que les utilisateurs de lecteurs d'écran ou d'autres technologies d'assistance bénéficient grandement des tableaux utilisant au mieux les fonctions d'accessibilité. Comprendre le sens d'un tableau long et complexe simplement en l'écoutant peut toujours s'avérer ardu, donc quoi qu'il arrive, essayez de le simplifier au maximum.

Il est moins évident de s'apercevoir que les designers et les utilisateurs de navigateurs visuels en bénéficient aussi : un tableau accessible possède de nombreuses balises structurelles auxquelles on peut appliquer des styles, et un bon design peut rendre le tableau plus facile à comprendre pour tout le monde.

Ce que je ne vous ai pas dit

Il y a beaucoup d'autres choses à dire sur les tableaux de données. Par exemple, je ne vous ai pas parlé du tout de l'attribut axis (jusqu'à maintenant), et je n'ai pas exploré en profondeur les possibilités des éléments <colgroups> et <col>. Je ne suis pas non plus rentré dans les détails de la mise en page et du design de tableau. Enfin je n'ai pas donné d'exemple concret de tableau vraiment complexe.

Pour ceux d'entre vous qui chercheraient plus d'informations à ce sujet, voici quelques liens vers des articles d'approfondissement :

  • Les tableaux dans les documents HTML
  • Mise en forme de tableaux à l'aide de CSS
  • Techniques pour des tableaux HTML accessibles
  • Construire des sites web accessibles : tableaux et cadres
  • À table, s'il vous plaît

Fiche technique

  • Article original : Bring on the tables
  • Auteur : Roger Johansson
  • Date de parution : 27 octobre 2004
  • Traduction : Pierre Equoy
  • Date de traduction : janvier 2005
  • Thème : Accessibilité
  • Niveau : Tous niveaux


Pompage.net - CSS : on reprend tout à zéro !

8 raisons de ne pas s’inscrire sur un site

Par Anthony T

S’inscrire sur un site web représente un engagement important pour beaucoup de gens. Les utilisateurs qui s’enregistrent sur votre site fournissent des informations personnelles et vous font confiance. Si vous utilisez ces informations à mauvais escient, ou si vous trompez leur confiance, vous pouvez les heurter sérieusement. La plupart des utilisateurs d’aujourd’hui sont plus méfiants que jamais quant à savoir qui va exploiter leurs données personnelles. Difficile de leur en vouloir, dans un cyber-monde qui regorge de hackers et de spammers. Cela veut dire que si vous n’obtenez pas beaucoup d’inscriptions, c’est que votre site envoie sans doute de mauvais signaux. Voici huit raisons qui peuvent expliquer pourquoi les utilisateurs ne remplissent pas les formulaires d’inscription.

1. La peur d’être spammé

La plupart des utilisateurs craignent de se faire spammer suite à leur enregistrement. C’est particulièrement vrai pour les inscriptions qui requièrent l’adresse email de l’utilisateur. Si vous devez demander une adresse email, assurez-vous de bien noter à côté du champ de saisie ce pour quoi vous avez besoin de cette adresse. Cela atténuera les craintes du spam, et rendra les utilisateurs plus enclins à vous fournir leur adresse email.

2. La peur qu’une inscription Facebook/Twitter ne spamme ses followers et ses amis

Les utilisateurs n’aiment pas être spammés, et ils n’aiment pas non plus spammer les autres. Les inscriptions liées aux comptes Facebook et Twitter arrosent souvent les followers et amis de notifications à la moindre action de l’utilisateur. Si vous comptez utiliser une inscription Facebook/Twitter, assurez-vous d’informer vos utilisateurs que l’application ne postera jamais de messages et de mises à jour de façon automatique.

3. L’impossibilité de supprimer son compte

Parfois, des utilisateurs s’inscrivent sur un site mais finissent par ne plus vouloir s’en servir. Si on donne à ces utilisateurs la liberté de supprimer leur compte, cela rassurera tous ceux qui ne veulent pas laisser de traces de leurs activités un peu partout sur le web. Informez-les dès votre formulaire d’inscription qu’ils pourront supprimer leur compte à tout moment, afin qu’ils ne s’inquiètent pas d’une conservation illimitée de leurs informations personnelles sur votre site.

4. Un sentiment de risque par rapport à la transmission d’informations personnelles

Lorsque des utilisateurs vous donnent des informations hautement sensibles, comme leur numéro de carte bancaire ou leur adresse personnelle, ils doivent savoir que votre site va gérer cette information de façon sécurisée. Cela signifie notamment qu’il faut crypter l’information sur les serveurs au cas où votre site serait piraté ou tomberait entre de mauvaises mains. Informez vos utilisateurs du fait que l’information stockée dans vos serveurs est cryptée et bien en sécurité.

5. Trop de travail à fournir, pour trop peu de retour

Si votre formulaire est long et exige beaucoup d’efforts pour le remplir, les utilisateurs vont comparer l’effort que vous leur demandez avec les avantages qu’ils espèrent tirer de votre site. Si ces avantages sont trop maigres, ils ne rempliront pas le formulaire. Si en revanche ils éprouvent un grand intérêt à s’inscrire, alors ils fourniront l’effort supplémentaire requis. De façon générale, le mieux est d’en demander le moins possible pour que personne ne se retrouve débordé. Vous pourrez toujours leur faire compléter leur profil une fois qu’ils seront inscrits.

6. Demander des informations qui ne semblent pas nécessaires

Tout ce que vous demandez aux utilisateurs devrait être lié à leur usage du site. Si l’utilisateur a le sentiment que vous lui réclamez quelque chose qui n’est pas nécessaire, soit il vous donnera une fausse information, soit il abandonnera votre formulaire. Si vous devez demander quelque chose qui risquerait de poser question à un utilisateur, ajoutez une note près du champ de saisie pour expliquer en quoi vous en avez besoin.

7. Se voir demander un numéro de carte bancaire pour un essai gratuit

Les essais gratuits permettent de tester un site pour voir s’il est utile avant de s’engager. Demander un numéro de carte bancaire pour un essai gratuit revient à demander aux utilisateurs de prendre un risque de sécurité important avant même qu’ils se soient engagés envers votre site. Même si vous ne comptez pas les débiter pendant leur période d’essai gratuit, la plupart des utilisateurs ne sont pas à l’aise avec l’idée de confier leur données bancaires juste pour essayer votre site. Laissez les utilisateurs profiter d’abord de leur essai gratuit, sans leur demander leur numéro de carte bancaire. Ensuite, lorsque la période d’essai touchera à sa fin, vous pourrez leur rappeler qu’ils doivent fournir leurs informations bancaires pour continuer à bénéficier des services proposés.

8. Le produit / service n’est pas clair ou pas engageant

Quand des utilisateurs visitent votre page d’accueil, ils doivent avoir une idée bien claire de ce que votre site peut leur offrir. Si ce n’est pas le cas, il faut retravailler votre page d’accueil. Les utilisateurs ne vont pas s’abonner à un site qu’ils ne comprennent pas ou qui ne les attire pas. Il faut les attirer en écrivant et en montrant clairement ce que votre site propose, et les avantages qu’ils tireront de son usage.

Les mots-clés : confiance et confort de l’utilisateur

Obtenir que les utilisateurs remplissent vos formulaires, c’est avant tout une question de confiance et de confort. La confiance des utilisateurs se gagne en prenant toutes les précautions de sécurité pour ce qui concerne leurs données, et en étant transparent quant aux raisons qui vous poussent à demander telle ou telle information. Mettez-les à l’aise en les laissant maîtres de leurs informations, et en ne leur demandant pas plus que le strict nécessaire pour l’étape de l’inscription. Si tout ceci peut être mis en œuvre sur un formulaire d’inscription, les utilisateurs n’auront aucune raison de ne pas le remplir.


Pompage.net - CSS : on reprend tout à zéro !

Concevoir des e-mails réactifs
Pour commencer

Par Campaign Monitor

Si vous lisez régulièrement vos e-mails sur un smartphone, vous savez sans doute que c’est une expérience qui peut virer au cauchemar. Telle newsletter, qui s'affiche pourtant très bien dans votre boîte de réception habituelle, peut devenir absolument illisible quand elle est réduite à un petit écran. Parmi les problèmes les plus fréquents, citons les polices trop petites, les colonnes trop étroites et les mises en page brisées.

Dans ce guide, nous allons voir pourquoi faire du design pour mobile est devenu une compétence nécessaire pour les designers d’e-mail, traiter les bases de la conception et de la construction d’un e-mail adapté aux terminaux mobiles et terminer avec quelques bons conseils et techniques. Nous partons du principe que vous connaissez le HTML pour les e-mails, mais si ce n’est pas le cas, nous avons également quelques excellents guides pour que vous vous lanciez.

Pourquoi optimiser vos e-mails pour mobile ?

Si vous envoyez des newsletters par e-mail, un nombre croissant de vos abonnés consulte probablement vos messages sur un iPhone, une tablette ou l’équivalent. Lors de notre dernière enquête de popularité sur les clients de messagerie en 2011, nous avons constaté que près de 20% des e-mails étaient ouverts sur mobile, ce qui représente une spectaculaire augmentation par rapport aux 4% du marché relevés dans les chiffres de 2009. Les appareils iOS représentaient 90% des affichages.

Pour les designers, cela signifie qu’il est tout aussi important que votre e-mail s’affiche de manière optimale sur mobile que dans les clients de messagerie historiques tels qu’Outlook et Gmail. De fait, l’utilisation de clients de messagerie mobile remplacera bientôt les clients e-mails en ligne et de bureau, ce qui signifie que fournir une expérience de lecture non optimale sur petit écran peut gêner non plus seulement quelques destinataires, mais au final la majeure partie de votre cible. Cela pourrait nuire au taux de réponse, ou comme le résumait Return Path dans un récent rapport :

« …ceux qui n’évaluent pas sur quel périphérique leurs abonnés lisent leurs e-mails, ou qui n’optimisent pas leurs e-mails ou sites web pour les périphériques mobiles risquent d’en pâtir. Une mauvaise expérience utilisateur pourrait signifier aucune réponse, aucune action, autrement dit, aucun retour sur investissement ; »

« e-mail in Motion: How Mobile is Leading the e-mail Revolution », Return Path, 2011

Nous verrons dans ce guide comment améliorer l’expérience e-mail sur mobile, de l’utilisation des requêtes de média lors de la construction de mises en page réactives à des techniques plus avancées. Nous aborderons également la conception des newsletters et comment adapter vos formulaires d’inscription pour les utilisateurs de smartphones.

Pour quels périphériques mobiles pouvez-vous concevoir ?

Tout d’abord une petite mise en garde – les techniques ci-dessous ne sont pas prises en charge par tous les clients de messagerie mobile. Comme vous le savez peut-être, les clients de messagerie ne sont pas tous égaux (et différents clients sur un même appareil n’ont pas le même rendu), c’est pourquoi l’affichage d’un e-mail peut varier radicalement d’une boîte de réception à une autre. Par exemple, alors que le client de messagerie Android que l’on retrouve sur le Google Nexus est célèbre pour son excellente compréhension des CSS, le client Gmail également fourni avec cet appareil ignore les styles en ligne et n’est pas fichu d’interpréter correctement plusieurs des propriétés CSS2 les plus couramment utilisées.

Heureusement, une forte proportion d’e-mails est lue sur l’iPhone et autres appareils Apple, qui affichent les e-mails pratiquement sans poser de problèmes.

En gardant cela à l’esprit, voici une liste non exhaustive de clients de messagerie mobile et de leur support des requêtes de média (en anglais, media query). Pour faire court, le support des requêtes de média vous permet d’utiliser de nombreuses techniques réactives (en anglais, responsive) que nous allons aborder dans ce guide.

Clients de messagerie par défaut

Client | Support des requêtes de média
Amazon Kindle Fire | Yes
Amazon Kindle Fire HD | Yes
Android 2.1 Eclair | No
Android 2.2+ | Yes
Apple iPhone | Yes
Apple iPad | Yes
Apple iPod Touch | Yes
BlackBerry OS 5 | No
BlackBerry OS 6+ | Yes
BlackBerry Playbook | Yes
Microsoft Windows Mobile 6.1 | No
Microsoft Windows Phone 7 | No
Microsoft Windows Phone 7.5 | Yes
Microsoft Windows Phone 8 | No
Microsoft Surface | No
Palm Web OS 4.5 | Yes

Clients de messagerie tiers

Client | Support des requêtes de média
Microsoft Outlook Exchange 3rd party app (Android) | No
Gmail mobile app (all platforms) | No
Yahoo ! Mail mobile app (all platforms) | No

Nous tenons à remercier chaleureusement Style Campaign qui nous aide à tester une grande partie des appareils ci-dessus. Lisez leur blog si vous vous intéressez à la conception d’e-mails pour mobile.

« Concevoir des e-mails réactifs » est une série de huit articles :

  1. Pour commencer
  2. Techniques de design
  3. Coder des e-mails pour les mobiles
  4. Concevoir des gabarits réactifs à nombre de colonnes variable
  5. Cibler des terminaux avec les media queries
  6. Optimiser les images pour le mobile
  7. Optimiser vos formulaires de souscription
  8. Étude de cas : Twitter

Fiche technique

  • Article original : Responsive Email Design: Getting started
  • Auteur : Campaign Monitor
  • Traduction : Aurélie Rigouste
  • Relecture : Nicolas Contant
  • Date de traduction : juin 2013
  • Thème : Web Mobile


Pompage.net - CSS : on reprend tout à zéro !

Concevoir des e-mails réactifs : Techniques de design

Par Campaign Monitor

Tout comme les nombreux concepteurs de sites qui ont une approche orientée design dans leurs projets, nous allons, dans ce guide, parler de l'aspect visuel des newsletters optimisées pour le mobile, avant de plonger les mains dans le code. Cela devrait vous aider à prendre les bonnes décisions la prochaine fois que vous planifierez une newsletter, et vous faciliter la compréhension des techniques dont nous allons discuter ensuite.

Le truc, c’est que nous allons créer deux gabarits CSS pour la même newsletter : un gabarit qui passe bien dans les webmails et les clients de messagerie de bureau, et un autre qui peut être lu facilement sur les petits écrans des terminaux mobiles. Par exemple, voici un e-mail HTML dans Outlook :

Juste en dessous, le même e-mail chargé dans l’application Mail sur l’iPhone d’Apple. Comme vous pouvez le voir, il y a des différences significatives entre ces deux gabarits. La version mobile est plus épurée, elle est moins chargée visuellement et elle est aussi lisible qu’une version pour ordinateur. Cela est dû à l’utilisation de CSS spécifiques :

À titre de comparaison, l’image de droite montre la même newsletter sans la CSS spécifique. Vous voyez comme le texte est minuscule et illisible ? Eh bien, c’est comme ça que s’affichent des millions de newsletters reçues sur des terminaux mobiles.

Gabarits et éléments adaptés au mobile

Concevoir pour mobile, cela ne se limite pas à essayer d’écrire des CSS spécifiques pour le mobile. Il y a d’autres points à prendre en compte :

  • Les gabarits à colonne unique d’une largeur maximum de 500 à 600 pixels fonctionnent mieux sur des terminaux mobiles. Ils sont plus faciles à lire, et en cas de problème d’affichage c’est généralement bien moins catastrophique.
  • Les liens et les boutons doivent avoir une taille minimum de 44 par 44 pixels selon les recommandations Apple. Rien n’est moins pratique qu’une foule de liens minuscules sur des écrans tactiles.
  • La taille minimum pour les textes est de 13 pixels. Gardez ceci en tête lorsque vous appliquez des styles sur du texte, car tout texte écrit plus petit sera agrandi et risque de détruire votre mise en page. Vous pouvez aussi passer outre ce comportement dans votre CSS (mais avec précaution).
  • Avant tout, gardez un message concis, et placez les éléments importants en tête d’e-mail si possible. Il est plus difficile de faire défiler une page sur des kilomètres avec un écran tactile qu’avec une souris.
  • Si possible, utilisez display:none; pour masquer les éléments non-pertinents de votre mise en page mobile. Par exemple les boutons de partage sur les réseaux sociaux seraient sans doute très acceptables dans un client de messagerie pour ordinateur, mais ne sont pas toujours faciles à utiliser sur des terminaux mobiles.

Lorsque vous maquettez un e-mail HTML ou un gabarit, notre conseil est de créer deux ébauches ou deux structures : une pour le rendu dans un webmail de bureau et l’autre pour le mobile. Gardez en tête l’emplacement où votre bouton d’action va apparaître sur l’un et l’autre : est-il immédiatement visible quand l’e-mail est ouvert ? Ou le destinataire doit-il faire défiler la page afin de le voir ?

Maintenant que vous avez vu de quoi sont capables les feuilles de style pour mobiles, allons faire un tour dans le code.

« Concevoir des e-mails réactifs » est une série de huit articles :

  1. Pour commencer
  2. Techniques de design
  3. Coder des e-mails pour les mobiles
  4. Concevoir des gabarits réactifs à nombre de colonnes variable
  5. Cibler des terminaux avec les media queries
  6. Optimiser les images pour le mobile
  7. Optimiser vos formulaires de souscription
  8. Étude de cas : Twitter

Fiche technique

  • Article original : Responsive Email Design : Design techniques
  • Auteur : Campaign Monitor
  • Traduction : Nicolas Contant
  • Relecture : Aurélie Rigouste
  • Date de traduction : juin 2013
  • Thème : Web Mobile

À propos de l'auteur

Campaign Monitor est une plate-forme d’e-mailing créée en 2004 par Ben Richardson et David Greiner, gérants d’une société de Web Design, à la suite de nombreuses demandes de la part de leurs clients pour gérer des campagnes d’envoi d’e-mails. Après avoir fait le tour des solutions existantes sur le marché, ils ont décidé de créer l’outil qui correspondait à leurs besoins.

Aujourd’hui, plus de 700 000 designers, agences et autres sociétés utilisent Campaign Monitor et de nouveaux clients les rejoignent régulièrement.
Ils continuent à ajouter de nouvelles fonctionnalités à leur produit et à le peaufiner mais leur objectif premier reste le même : rendre plus facile pour quiconque l’envoi et la gestion de jolies newsletters.


Pompage.net - CSS : on reprend tout à zéro !

Concevoir des e-mails réactifs : Coder des e-mails pour les mobiles

Par Campaign Monitor

Lorsque les concepteurs de sites parlent de feuilles de style pour les mobiles, ils ne parlent pas de feuilles de styles totalement distinctes, mais des trucs sympas qui apparaissent entre les accolades des requêtes de média.

Voici à quoi cela ressemble :

<style type="text/css">
   @media only screen and (max-device-width: 480px) {
       /* placer les CSS conçues pour les mobiles ici */
   }

   /* les CSS classiques sont à placer ici */
</style>

Voyons à quoi sert cette déclaration @media. Premièrement, afin d’en faire un élément spécifique au mobile, il faut respecter certains critères avant que le client de messagerie de l’utilisateur n’applique les styles déclarés à l’intérieur. La déclaration @media only screen signifie que l’e-mail sera présenté sur un écran (et non pas sur une plage braille ni sur une feuille imprimée).

En plus de cela, la zone de visualisation du périphérique ne peut être supérieure à 480px (largeur maximum). C’est important, parce que tous les terminaux mobiles n’ont pas une zone de visibilité de 480px maximum. Même si la règle max-device-width: 480px est couramment utilisée (dans la mesure où c’est la largeur d’un écran d’iPhone en mode paysage), vous pouvez la bidouiller pour vous adapter à des écrans plus larges comme ceux des tablettes. Vous pouvez même vous la raconter à mort en écrivant ceci :

@media screen and (device-width: 480px) and (device-height: 360px), screen and (device-width: 360px) and (device-height: 480px), screen and (device-width: 320px) and (device-height: 240px) { ... }

Maintenant, il est temps de regarder notre premier essai d’e-mail qui a été réduit pour un terminal mobile. Voici le design dans iPhone Mail :

Dans cet exemple, nous avons appliqué la classe tableaudecontenu aux tableaux HTML qui contiennent le texte et les images. Voici un extrait du code :

<style type="text/css">
   @media only screen and (max-device-width: 480px) {
   /* placer les CSS conçues pour les mobiles ici */
       table[class=tableaudecontenu] {
           width: 320px !important;
       }
   }

   /* les CSS classiques sont à placer ici */
   table.tableaudecontenu {
       width: 640px;
   }
</style>

La classe tableaudecontenu a un effet vraiment intéressant ici : quand l’e-mail est consulté sur un terminal dont l’écran est de 480px ou plus, rien ne se passe. Cependant, lorsque l’écran est de 480px ou moins, cela réduit les tableaux à 320px de large. Les sélecteurs d’attribut ont été utilisés afin d’éviter un comportement surprenant dans Yahoo ! Mail.

Nous avons également ajouté !important ; aux règles de styles spécifiques au mobile pour nous assurer qu’elles prennent le pas sur toutes les autres. En dehors de ça, c’est une CSS tout ce qu’il y a de plus ordinaire. De la même manière, vous pourriez la doter d’autres déclarations telles que :

@media only screen and (max-device-width: 480px) {
   /* placer les CSS conçues pour les mobiles ici */
   table[class=tableaudecontenu] { width: 325px !important; }
   img[class="imagedentete"] { width: 325px !important;  }
   p[class="date"] { display: none !important; }
}

Maintenant que vous avez un avant-goût de la manière dont le code fonctionne, nous vous recommandons de télécharger notre gabarit d’e-mail pour l’étudier de près. En espérant que ces quelques exemples vous ont parlé, nous allons à présent étudier quelques techniques plus avancées pour adapter votre newsletter aux terminaux mobiles. Attachez vos ceintures !

« Concevoir des e-mails réactifs » est une série de huit articles :

  1. Pour commencer
  2. Techniques de design
  3. Coder des e-mails pour les mobiles
  4. Concevoir des gabarits réactifs à nombre de colonnes variable
  5. Cibler des terminaux avec les media queries
  6. Optimiser les images pour le mobile
  7. Optimiser vos formulaires de souscription
  8. Étude de cas : Twitter

Fiche technique

  • Article original : Coding mobile emails
  • Auteur : Campaign Monitor
  • Traduction : Nicolas Contant
  • Relecture : Aurélie Rigouste
  • Date de traduction : juillet 2013
  • Thème : Web Mobile


Pompage.net - CSS : on reprend tout à zéro !

Concevoir des e-mails réactifs : Gabarits réactifs

Par Campaign Monitor

Il est généralement recommandé de choisir un gabarit à une seule colonne quand on veut que ses e-mails soient optimisés pour mobile, mais il existe une technique élégante pour créer des gabarits réactifs à deux colonnes sans devoir écrire des kilomètres de CSS.

Alors que les gabarits à 2 colonnes permettent souvent d’afficher plus de contenu au-dessus de la ligne de flottaison avec un client de messagerie de bureau comme Outlook, ils sont beaucoup plus difficiles à lire et à parcourir sur les périphériques mobiles. Nous allons corriger cela en codant un peu à l’ancienne.

Une des règles d’or du design pour e-mail dit ceci : « dans la mesure du possible, utilisez des attributs HTML au lieu des CSS ». Alors que l’interprétation des CSS peut être assez inégale au vu de la diversité des clients de messagerie, les attributs ont tendance à être solides comme le roc. Par exemple, les attributs comme align=”left” et cellpadding=”10” sont beaucoup plus fiables que leurs équivalents CSS, float: left; et padding: 10px;. C’est exactement ces attributs que nous allons utiliser pour construire notre gabarit à 2 colonnes linéarisables.

Observons un gabarit de ce genre dans Outlook 2007 :

Dans l’exemple ci-dessus, nous avons un tableau de 640px de large, les 2 colonnes intérieures étant à leur tour des tableaux de 320px de large, comme dans nos exemples précédents.
Ces colonnes ont un cellpadding=”20” appliqué pour que le contenu n’aille se coller aux bords disgracieusement.

En codant pour le web, on utiliserait généralement float: left; sur la colonne de gauche, pour les positionner côte-à-côte. Mais à la place, on peut utiliser align=”left”. Tant que la largeur du tableau principal est supérieure ou égale à la largeur combinée des deux colonnes intérieures, elles vont parfaitement s’adapter. Voici le code simplifié pour un gabarit à 2 colonnes :

<table width="640" border="0" cellpadding="0" cellspacing="0">
    <tr>
        <td>
            <table width="320" border="0" cellspacing="0" cellpadding="20" align="left">
                <tr>
                    <td><p>Contenu de la colonne de gauche</p></td>
                </tr>
            </table>
            <table width="320" border="0" cellspacing="0" cellpadding="20">
                <tr>
                    <td><p>Contenu de la colonne de droite</p></td>
                </tr>
           </table>
       </td>
    </tr>
</table>

Le résultat :

Si le tableau principal fait 640px de large, vous obtiendrez un gabarit à 2 colonnes. Mais il suffit de retirer rien qu’un pixel pour forcer la colonne de droite à aller se positionner sous celle de gauche. Pour peu que le tableau extérieur soit de même largeur que les tableaux intérieurs (320px), vous obtenez un parfait gabarit à une colonne qui correspond exactement à l’écran d’un iphone, sans zoom nécessaire. Le tout en ne rajoutant qu’une seule requête de media dans votre code HTML :

<style type="text/css">
@media only screen and (max-device-width: 480px) {
    table[class=tableaudecontenu] {
        width:320px !important;
    }
}
</style>

<table width="640" border="0" cellpadding="0" cellspacing="0" class="tableaudecontenu">

Et voilà un gabarit à 2 colonnes sur les clients de messagerie en ligne et de bureau qui passe sur 1 colonne pour les clients de messagerie iPhone et Android.

Ajouter l’affichage progressif façon Wikipédia

Sur le web, de nombreux sites réactifs convertissent les longs formulaires en formulaires ultra-courts pour les périphériques mobiles en utilisant une technique appelée l’« affichage progressif ». Il s’agit de cacher du contenu derrière un élément interactif comme un bouton ou un lien, puis de l’afficher au clic (ou au tap). Wikipédia l’utilise, comme beaucoup d’applications mobiles. On peut aussi l’utiliser dans les e-mails sur mobile. Afficher ou masquer du contenu dynamiquement en pur CSS

Prenons une newsletter contenant plusieurs articles. Dans les clients de messagerie de bureau, nous voulons afficher un titre et le contenu de chaque article :

Toutefois, sur les clients mobiles, nous voulons uniquement afficher le titre avec un bouton Afficher/Masquer à côté (qui gère l’affichage du texte). Cela transforme l’e-mail en un tableau de contenu interactif, ce qui réduit considérablement la longueur du message :

Pour ce faire, nous allons tout d’abord nous tourner vers le code HTML et créer un article avec un titre, du texte et un bouton Afficher/Masquer. Nous allons également ajouter quelques classes pour afficher le bouton uniquement sur les périphériques mobiles. Voici une version simplifiée du code de chaque article.

<td>
    <h4><a href="http://votredomaine.com" class="link">Premier titre</a></h4>
    <a href="#" class="mobilemasquer">Masquer</a> <a href="#" class="mobileafficher">Afficher</a>
    <div class="article">
        <p class="corpsdetexte">
            <img src="kitten.jpg" style="float: left;" >Pellentesque habitant morbi...
        </p>
        <a href="http://votredomaine.com">Lire la suite...</a>
    </div>
</td>

Notez bien les classes mobilemasquer, mobileafficher et article : celles-ci vont se charger du gros du travail.

Dans notre feuille de style, nous allons cacher le bouton Afficher/Masquer lorsque l’e-mail est affiché dans un client de messagerie en ligne ou de bureau, en utilisant display: none; dans notre feuille de style comme ceci :

a[class="mobileafficher"], a[class="mobilemasquer"] {
    display: none !important;
}

Pour être sûrs que les boutons Afficher/Masquer ne sont visibles que sur les appareils mobiles, nous allons passer aux requêtes de média. Voici le code, comprenant les propriétés utilisées par .mobileafficher et .mobilemasquer et quelques styles de boutons adaptés pour webkit en bonus... :

@media only screen and (max-device-width: 480px) {
    a[class="mobileafficher"], a[class="mobilemasquer"] {
        display: block !important;
        color: #fff !important;
        background-color: #aaa;
        border-radius: 20px;
        padding: 0 8px;
        text-decoration: none;
        font-weight: bold;
        font-family: "Helvetica Neue", Helvetica, sans-serif;
        font-size: 11px;
        position: absolute;
        top: 25px;
        right: 10px;
        text-align: center;
        width: 40px;
    }
    div[class="article"] {
        display: none;
    }
    a.mobileafficher:hover {
        visibility: hidden;
    }
    .mobileafficher:hover + .article {
        display: inline !important;
    }
}

Et si tout se passe bien, vous devriez obtenir un e-mail avec des boutons Afficher/Masquer qui gèrent l’affichage du contenu sur iPhone. Si vous voulez vous exercer à cette technique pour vos propres campagnes d’e-mails, n’hésitez pas à télécharger gratuitement notre exemple (sur Github) et à l’adapter à vos besoins. Nous en profitons pour remercier chaleureusement Eric Gideon pour sa contribution à ce projet.

« Concevoir des e-mails réactifs » est une série de huit articles :

  1. Pour commencer
  2. Techniques de design
  3. Coder des e-mails pour les mobiles
  4. Concevoir des gabarits réactifs à nombre de colonnes variable
  5. Cibler des terminaux avec les media queries
  6. Optimiser les images pour le mobile
  7. Optimiser vos formulaires de souscription
  8. Étude de cas : Twitter

Fiche technique

  • Article original : Responsive Email Design : Building responsive 2-to-1 column layouts
  • Auteur : Campaign Monitor
  • Traduction : Aurélie Rigouste
  • Relecture : Nicolas Contant
  • Date de traduction : juillet 2013
  • Thème : Web Mobile


Pompage.net - CSS : on reprend tout à zéro !

Concevoir un design sans la couleur

Par Mark Boulton

La conception d'un design efficace est une affaire délicate, et souvent rendue plus difficile encore par les choix de couleurs. Pourquoi ne pas imaginer un mode initial de conception qui s'affranchisse totalement de la couleur au profit d'un travail sur les tons?

Faire un design en travaillant sur la couleur, c’est peut-être l’une des choses les plus difficiles à faire dans le domaine du design graphique. Pourquoi ? Parce qu’il n’y a rien de plus subjectif. Certains trouveront génial de choisir une palette de gris sombre avec quelques touches de rose vif, tandis que d’autres trouveront ça très laid. On voit trop souvent des designers prendre des décisions arbitraires sur cette question, qu’ils soient ou non formés à la théorie chromatique, et c’est au moment où ils tentent de justifier ces choix auprès de leurs clients que tout se complique. Dans ce premier article, je vais m’intéresser aux tons et à l’avantage qu’on trouvera à limiter l’étendue de sa palette.

On baisse d’un ton

Il y a quelques années (houlà, ça fait même une bonne quinzaine d’années…) j’étais en première année aux Beaux-Arts, ici à Stockport au Royaume-Uni. Je voulais devenir peintre, ou plus exactement illustrateur. Dès la première semaine, on nous a demandé de nous débarrasser de tous les beaux pinceaux qu’on venait de s’acheter pour les cours. Nous avons donc dû laisser notre matériel tout neuf à la maison, puis aller dehors récolter des brindilles et dénicher de l’encre noire. Je n’étais vraiment pas enthousiaste. Comment imaginer qu’un artiste puisse créer à l’aide d’outils aussi primitifs ?
Nos professeurs nous ont donc fait peindre avec des brindilles, puis avec nos pieds, puis les yeux bandés : bref, la totale. À l’époque j’ai trouvé ça nul, et je ne comprenais pas où ils voulaient en venir. Maintenant que j’ai pris du recul, je perçois bien l’intérêt de cet horrible démarrage. Ils nous apprenaient à observer et à produire des œuvres qui n’étaient pas dictées par nos outils. En d’autres termes, si nous avions disposé de couleurs variées et de beaux pinceaux, la tentation de les exploiter aurait été trop grande. Faute de pinceaux et de couleurs, nous avons été contraints de communiquer la notion de couleur uniquement avec des effets de ton.
C’est par cela que je voudrais commencer.

Faisons sans la couleur

L’une des choses que j’apprécie dans le design éditorial, et en particulier dans le design typographique, c’est l’importance du noir et blanc. Bien sûr, la couleur constitue une étape très importante de tout travail typographique, mais je m’intéresse avant tout au ton et à la forme. Je crois qu’il y a tout à gagner à retirer complètement la couleur de l’équation afin de focaliser sur les questions de tonalité d’un design, avant d’y appliquer des couleurs.
Quelques exemples notables suffiront à montrer qu’un design basé seulement sur du noir peut être original et attirant.
On ne saurait parler du design web en noir et blanc sans évoquer le site de Khoi Vinh, Subtraction.com. Khoi travaille avec du noir et de l’orange pour correspondre au style suisse du design (ou style typographique international, NdT).

Le site Substraction.com par Khoi Vinh

Form, un magazine de design allemand, utilise une typographie en noir et blanc (basée sur une grille rigoureuse) pour transmettre son concept de marque aux utilisateurs du site. On voit l’effet qui est atteint avec ce noir et blanc : l’ouvrage qui est mis en lumière, avec sa couleur vive, se détache très nettement du cadre noir et blanc.

Le magazine allemand de design Form

D’abord du gris

Faites donc le test pour votre prochain design. Comme indiqué dans le titre, contentez-vous de le démarrer avec du gris en différentes nuances. N’ajoutez aucune couleur tant que vous n’êtes pas satisfait du design en noir et blanc. Il y a de grandes chances que les décisions de palette et de couleurs que vous prendrez seront ensuite beaucoup plus simples, parce que le design ne dépendra plus de la couleur pour fonctionner. C’est particulièrement pertinent si on cherche à créer un design avec une bonne accessibilité. Ce n’est pas le sujet de cet article, puisque je me concentre ici sur le design graphique, mais l’accessibilité reste néanmoins une question qui ne doit pas être négligée. En basant votre design sur le noir et blanc, vous vous assurez que la solution retenue ne dépendra jamais de la couleur.
J’utilise souvent la couleur pour mettre des éléments du design en avant, mais en général ils ont déjà un rôle dans le graphisme retenu, comme par exemple les lignes horizontales du site ci-dessous. On peut aussi imaginer mettre en valeur un bouton de recherche, ou bien les éléments d’une barre de navigation. La couleur sert alors à faire ressortir des éléments fonctionnels cruciaux de l’interface.

On résout d’abord les questions de tons avant d’appliquer de la couleur

Vers des palettes mono- et duo-tonales

Dans mon prochain billet, je vais aller un peu plus loin avec mes gris.
On a quand même de la chance, nous les designers du web. On peut employer pratiquement n’importe quelle couleur. Les designers papier, eux, sont confrontés à des limites sur l’usage des couleurs depuis l’origine de l’imprimerie. Du coup, cela les a rendus très attentifs à ces questions du design en couleur. Je trouve qu’il n’y a rien de plus formateur que de créer des projets à une ou deux couleurs, mais appliquées à un grand nombre de situations, afin de mieux réfléchir à la façon dont la couleur est employée. Je vais essayer d’évoquer cet axe de réflexion (et cette contrainte) dans mon prochain billet.

Cet article fait partie de l’ouvrage « Five Simple Steps: Designing for the Web » écrit par Mark Boulton en 2006. La suite de l’article est disponible en anglais sur son site : deuxième et troisième partie.

Fiche technique

  • Article original : Five Simple Steps to designing with colour
  • Auteur : Mark Boulton
  • Date de parution : 19 octobre 2006
  • Traduction : Frédéric Chotard
  • Relecture : Nicolas Contant
  • Date de traduction : septembre 2014
  • Thèmes : Design, Web design


Pompage.net - CSS : on reprend tout à zéro !

Concevoir des e-mails réactifs : Optimiser vos formulaires de souscription

Par Campaign Monitor

Optimiser vos campagnes e-mail pour mobiles ne se limite pas à s’assurer que votre newsletter peut être lue sur de petits écrans. Après tout, à quoi sert de diffuser des campagnes optimisées pour les mobiles si les utilisateurs de mobile ne peuvent même pas s’y abonner ?

Bonne nouvelle : à l’heure actuelle les formulaires sont relativement faciles à remplir sur les terminaux mobiles type iPhone ou Android, mais les designers et développeurs peuvent faire quelques petits trucs pour les rendre aussi faciles à utiliser que possible. Optimiser vos formulaires les rendra plus rapide et plus facile à remplir sur un terminal mobile, vous aurez donc un meilleur taux de transformation et plus d’abonnés.

Voici quelques indicateurs et un exemple simple que vous pouvez utiliser comme point de départ pour vos propres formulaires d’abonnement.

  • Aligner les labels au-dessus des champs. Sur mobile, les labels disparaissent fréquemment de l’écran quand un champ est sélectionné. Au niveau de zoom initial, un label aligné à gauche tel que « entrez votre adresse e-mail : » est visible, mais dès que vous commencez à saisir du texte, l’appareil zoome sur le champs et le label se retrouve masqué au loin. Pour éviter cela, il faut aligner le label au-dessus du champ concerné, ou le reprendre comme valeur par défaut du champ. Cette deuxième solution économise l’espace vertical mais a pour inconvénient que l’information disparaît à la prise de focus du champ, qui peut avoir été caché jusque-là par « l’assistant formulaire » du téléphone ou par le clavier.
  • Utiliser input type=”e-mail”. Si vous utilisez un input de type e-mail, un clavier spécialement adapté sera affiché sur les terminaux iOS, sur lequel il est plus aisé de saisir des caractères tels que l’@.
  • Réduisez la largeur de vos formulaires (à défaut du site en entier) : utiliser les requêtes de média pour ajouter des CSS ciblant spécifiquement les mobiles permet de grandement réduire l’encombrement à l’écran, ce qui améliore l’utilisabilité des formulaires. Et puis, rien n’est plus pénible qu’un champ de texte qui ne tient pas entièrement à l’écran. Personnellement, je préfère utiliser des gabarits fluides pour terminaux mobiles, tout simplement parce qu’il est impossible de prévoir les dimensions ou l’orientation de l’écran. Il suffit de définir la largeur des champs texte à une valeur comme 80% pour rendre les formulaires de souscription bien plus agréable à consulter et à remplir.
  • Attention aux champs multi-options. Dans un gabarit étroit, forcer le contenu à s’afficher en colonne est bien plus prudent – en particulier les cases à cocher. Quand différentes options se retrouvent sur plusieurs lignes, les choses deviennent rapidement assez compliquées. Il vaut souvent mieux utiliser un bonne vieille liste déroulante que des boutons radio, qui a également l’avantage de limiter le défilement nécessaire pour naviguer dans le formulaire.
  • Prenez position sur la taille. Au final, pas mal de ces astuces ne sont pas spécifiques aux formulaires – elles concernent plus le webdesign en général. Y compris l’idée de fixer les dimensions d’affichage sur terminal mobile en utilisant la balise « meta viewport », tout particulièrement quand vous développez des formulaires autonomes. Cette balise permet d’éviter que l’utilisateur ne zoome accidentellement et perde de vue la plupart du formulaire. Voici la syntaxe classique de la balise meta viewport, à placer dans le <head> d’une page HTML : <meta name = "viewport" content = "width = device-width, user-scalable = no" /> Pour les variantes, lisez la documentation du meta tag viewport d’Apple.

Pour vous montrer comment optimiser vos formulaires, nous avons créé un gabarit CSS simple dans lequel vous pouvez insérer le formulaire de souscription sous sa forme la plus basique. Vous pouvez voir ce que ça donne dans votre navigateur ou votre terminal mobile en suivant ce lien : http://goo.gl/7xDuu.

Vous pouvez reprendre la CSS, jouer avec les requêtes de média et l’utiliser soit comme formulaire autonome, soit sur vos propres pages.

Créer des e-mails texte adaptés au mobile

Ne souhaitant pas limiter nos conseils au design des e-mails HTML, nous avons voulu ajouter quelques trucs pour optimiser les campagnes d’e-mails en texte brut. Concernant le formatage, il y a deux écoles : ceux qui reviennent à la ligne tous les 60-65 caractères, et les autres. Les deux ont leurs avantages et inconvénients, tout dépend du client e-mail sur lequel vous regardez le message.

La technique des 60-65 caractères fonctionne bien pour les clients de messagerie de bureau et les webmails parce que les paragraphes peuvent être affichés dans des fenêtres ou des panneaux de prévisualisation qui n’imposent pas de largeur maximum. Une ligne de plus de 60 caractères environ perd en lisibilité car l’œil se fatigue beaucoup à revenir au début de la ligne suivante et la lecture est très ralentie.

Les choses sont très différentes sur mobile cependant. Quand les retours à la ligne tous les 65 caractères se combinent avec ceux imposés par l’application elle-même, les décrochements finissent par rendre le texte plus illisible encore que s’il se présentait sur une seule ligne.

La plupart des clients mobiles affichent directement la version HTML de vos e-mails, du coup même si la version texte brut de vos messages contient des retours à la ligne, il n’est pas vraiment utile de revenir dessus car l’application produit d’elle-même un joli formatage. Si toutefois vous envoyez des campagnes en texte brut uniquement, il vaut mieux étudier les statistiques de consultation de vos e-mails avant de choisir l’une ou l’autre méthode. Si un grand nombre d’inscrits lisent leurs e-mails sur un terminal mobile, ajouter vos propres retours à la ligne serait contre-productif ; si ce n’est pas le cas, il peut être utile de consacrer un peu de temps au formatage.

Fiche technique

  • Article original : Responsive Email Design : Optimizing your subscribe forms
  • Auteur : Campaign Monitor
  • Traduction : Nicolas Contant
  • Relecture : Aurélie Rigouste
  • Date de traduction : octobre 2013
  • Thème : Web Mobile


Pompage.net - CSS : on reprend tout à zéro !

Concevoir des e-mails réactifs : Optimiser les images pour le mobile

Par Campaign Monitor

La surface d’écran disponible étant limitée sur les terminaux mobiles, nous devons être prudent quand il s'agit d’ajouter des images aux e-mails HTML. L'iPhone ayant un très bon support des CSS, il est cependant possible d'insérer des images de manière créative.

Dans ce chapitre, nous allons étudier quelques techniques qui tirent profit de propriétés CSS bien supportées comme background-image. Ces techniques ne vont pas seulement vous permettre de proposer des images optimisées pour le mobile à travers vos designs, mais aussi vous assurer qu’elles soient impeccables à n’importe quelle taille.

Utiliser les images de fond pour de meilleurs en-têtes

Nous ne recommandons habituellement pas d’utiliser les images de fond dans un gabarit d’e-mail, mais le support des CSS et des requêtes de média de l’iPhone et du client mail par défaut d’Android est suffisamment solide pour que les avantages soient substantiels.

Parmi ceux-ci, il y a la possibilité de remplacer les images d’origine par celles que vous aurez optimisées pour le mobile en les masquant quand votre e-mail est consulté depuis un terminal mobile.

Jusqu’à maintenant, nous recommandions que les images soient redimensionnées pour les terminaux mobiles. Toutefois, le problème avec cette façon de faire est que l’information contenue dans l’image peut se révéler trop petite pour être bien lue ou comprise.

Une solution plus intéressante consiste à créer une image spécifique pour les abonnés consultant leurs e-mails sur mobile. Pour cela, nous allons placer l’image dans une cellule de tableau ou une div, puis écrire une requête de média qui masquera cette image et en affichera une autre, plus adaptée, en image de fond :

CSS

@media only screen and (max-device-width: 480px) {
   td[class="entetedecellule"] {
       background-image: url(images/en_tete-325.png);
       width: 325px !important;
       height: 115px !important;
   }
   td[class="entetedecellule"] img {
       display: none;
   }
}

HTML

<table width="100%" border="0" cellspacing="0" cellpadding="0">
  <tr>
     <td class="entetedecellule">
       <img src="images/en_tete.png" border="0" width="600" />
   </td>
  </tr>
</table>

Voici à quoi les choses ressemblent avant et après que les images aient permuté :

L’avantage avec cette technique, c’est que vous pouvez raccourcir la longueur des e-mails en utilisant des images moins hautes (cf ci-dessus). Sur un e-mail mobile, plus c’est court, mieux c’est.

Le problème avec la méthode de permutation des images de fond, c’est que cela ne se révèle vraiment efficace qu’avec des e-mails à largeur statique. Or, ces temps-ci, les terminaux mobiles pouvant prendre n’importe quelle forme ou taille d’écran, la grille fluide devient une option répandue. Même si la solution logique semble être celle du background-size: 100% dans la requête de média précédente, la meilleure combine est celle consistant à utiliser background-size: cover ainsi que le précise Elliot Jay Stocks :

@media only screen and (max-device-width: 480px) {
    td[class="entetedecellule"] {
        background-image: url(images/en_tete-480.png) !important;
        background-size: cover;
        }
    td[class="entetedecellule"] img {
        display: none;
        }
}

Heureusement, les clients e-mail sous Webkit supportent totalement la règle background-size, ce qui signifie que vous ne risquez rien avec le client mail par défaut de iOS et Android. Si vous avez un doute, on vous recommande la méthode traditionnelle qui consiste à utiliser une balise img dans un gabarit fluide et de la redimensionner comme ceci :

@media only screen and (max-device-width: 480px) {
    td[class=entetedecellule] img {
        height:auto !important;
        width:100% !important;
    }
}

Proposer des images en haute résolution pour les écrans Retina

Notre dernier conseil concerne les images que l’on cherche à rendre aussi nettes que possibles sur des écrans Retina. On en a déjà parlé avant, mais dans la mesure où ce type d’écran devient de plus en plus courant, cela mérite un petit résumé.

Le truc, c’est de créer des images-clés deux fois plus grandes que celles que vous comptez placer, ce qui offre un rendu impeccable sous iPhone 4, 4s et iPad. Par exemple, en utilisant notre hack avec background-image cité plus haut, nous avons créé un en-tête en image qui faisait vraiment 650 × 230 px (il s’agit de en_tete-325@2x.png), mais qui rétrécit sur les écrans des mobiles. Voici à quoi la requête de média pourrait ressembler :

@media only screen and (max-device-width: 480px) {
    td[class="entetedecellule"] {
        background-image: url(images/en_tete-650@2x.png) !important;
        background-size: 325px 115px;
        width: 325px !important;
        height: 115px !important;
        }
    td[class="entetedecellule"] img {
        display: none;
        }
    }
}

Si vous souhaitez cibler uniquement les écrans Retina avec une feuille de style particulière, vous pouvez utiliser cette déclaration CSS à la place :

@media all and (min-device-pixel-ratio : 1.5) { ... }

Pour plus d’informations sur cette utilisation, nous vous recommandons de lire ce billet de Ben Frain.

Tandis que cette image d’en-tête sera super nette uniquement sur les terminaux en question, le problème à résoudre est que tout le support des requêtes de médias du client e-mail sera alourdi par le téléchargement de l’image en haute définition.

En effet, l’inconvénient à utiliser ce type de technique est que les images plus grosses auront forcément des tailles plus importantes, augmentant le temps de chargement dans la boîte de réception. Par conséquent, utilisez cette technique judicieusement, car tout le monde n’est pas équipé pour bénéficier d’images en haute résolution.

« Concevoir des e-mails réactifs » est une série de huit articles :

  1. Pour commencer
  2. Techniques de design
  3. Coder des e-mails pour les mobiles
  4. Concevoir des gabarits réactifs à nombre de colonnes variable
  5. Cibler des terminaux avec les media queries
  6. Optimiser les images pour le mobile
  7. Optimiser vos formulaires de souscription
  8. Étude de cas : Twitter

Fiche technique

  • Article original : Optimizing images for mobile
  • Auteur : Campaign Monitor
  • Traduction : Nicolas Contant
  • Relecture : Aurélie Rigouste
  • Date de traduction : septembre 2013
  • Thème : Web Mobile


Pompage.net - CSS : on reprend tout à zéro !

Concevoir des e-mails réactifs : Étude de cas - Twitter

Par Campaign Monitor

Maintenant que nous avons abordé la théorie, mettons quelques-unes de ces techniques en pratique avec un cas concret. Mais pas avec n’importe quel e-mail : un e-mail qui est envoyé à des millions de personnes chaque jour.

Dans un passé pas si lointain, les notifications par e-mail de Twitter s’affichaient de manière sous-optimale sur les périphériques mobiles. Le texte de petite taille combiné à une mise en page large qui obligeait l’appareil à dézoomer rendait l’e-mail presque illisible sur les petits écrans.

Nous avons décidé de faire quelque chose pour remédier à cela. En 5 minutes, nous avons appliqué un correctif simple qui fait toute la différence dans la facilité d’utilisation et la lisibilité des notifications... Et qui peut aussi potentiellement aider à améliorer de manière significative la façon dont vos propres campagnes e-mail s’affichent sur les périphériques mobiles.

Dans cette étude de cas, nous allons vous montrer comment nous avons transformé une notification e-mail basique en quelque chose de remarquable sur l’application e-mail iPhone ou Android, ou tout autre client de messagerie mobile gérant les requêtes de média.

Contrôler la taille du texte

Nous avons commencé par chercher comment régler le problème le plus évident de ces notifications : le texte minuscule. La raison pour laquelle le texte paraît si petit est que la mise en page de 710px de large force le client de messagerie mobile à dézoomer considérablement pour afficher le message dans toute sa largeur. Corrigeons cela avec une requête de média ciblant les petits écrans :

@media only screen and (max-width: 480px) { ... }

Si vous vous y connaissez en design réactif pour e-mail, vous devez savoir que ces déclarations s’ajoutent dans les balises <style>, les styles définis à l’intérieur ne sont appliqués que par les clients de messagerie HTML qui correspondent aux critères : un écran (@media only screen) et de largeur maximum 480px (max-width : 480px). Nous voici donc à même d’adapter la mise en page pour mobile. Prenons tout d’abord les deux tableaux qui entourent le corps du message :

<table cellspacing="0" cellpadding="0" border="0" width="100%">
<tr>
<td style="background-color:#e9eff2; padding: 30px 15px 0;"><table cellspacing="0" cellpadding="0" border="0" align="center" width="710" style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 16px; color: #333;">

Nous allons réduire leur taille en ajoutant les classe tableauglobal, celluleglobale et structure :

<table cellspacing="0" cellpadding="0" border="0" width="100%" class="tableauglobal">
<tbody>
<tr>
<td style="background-color:#e9eff2;padding:30px 15px 0" class="celluleglobale"><table cellspacing="0" cellpadding="0" border="0" align="center" width="710" style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:16px;color:#333" class="structure">

Maintenant que nous avons des éléments à cibler, travaillons sur ces classes dans notre requête de média :

@media only screen and (max-device-width: 480px) {
   body {
       width: 320px !important;
   }
   table[class="tableauglobal"] {
       width: 320px !important;
   }
   table[class="structure"] {
       width: 300px !important;
}

Les largeurs utilisées ci-dessus ne sont pas arbitraires car sur l’iPhone notamment, la largeur d’affichage est de 320px en mode portrait. Réduire les dimensions de l’e-mail à 320px font qu’il s’affichera avec un zoom de 100% par défaut, rendant le design directement visible en entier, et le texte et les images parfaitement nets.

Contrôler l’image d’en-tête

La technique ci-dessus serait parfaite s’il n’y avait pas cette large image « Twitter » dans l’en-tête. Nous allons donc ruser un peu et diviser cette image en 3. Les sections qui n’ont pas besoin d’être affichées dans notre gabarit plus étroit seront tout simplement masquées. Voici le code original :

<img alt="Twitter" height="52" src="http://a0.twimg.com/a/1335832060/images/e-mail/e-mail_entete_710.png" style="border: 0; display: block;" width="710" />

Et le voici avec l’image d’en-tête en 3 morceaux :

<img alt="" height="52" src="logo-gauche.png" style="border:0;" width="41" class="logo"><img alt="Twitter" height="52" src="logo.png" style="border:0;" width="320"><img alt="" height="52" src="logo-droite.png" style="border:0;" width="336" class="logo">

Vous avez peut-être remarqué que nous avons ajouté la classe logo sur logo-gauche.png et logo-droite.png. Il est assez facile de cacher ces éléments, en ajoutant le code suivant dans votre requête de média :

img[class="logo"] { display: none !important; }

Nous voilà donc avec une image d’en-tête et un gabarit adaptés à la taille d’écran des mobiles.

Pour compléter les ajustements ci-dessus, nous avons ajouté de la marge intérieure autour des éléments et ajusté la taille du texte à notre convenance. Mais en fin de compte, la plupart des changements majeurs ont été obtenus avec quelques lignes de code et en quelques minutes seulement. Le résultat parle de lui-même (voir image).

Des centaines de personnes ont manifesté leur soutien à ces changements et se sont joints à nous pour inciter Twitter à améliorer ses notifications. La bonne nouvelle, c’est que Twitter nous a entendus et a effectué une refonte majeure de ses notifications e-mail dans la semaine qui a suivi.

Vous aussi vous pouvez faire plaisir à une communauté, bien sûr plus réduite, en appliquant ces améliorations à vos propres e-mails. Voici le code, que vous pouvez librement tester et adapter à vos propres campagnes :

Télécharger le code

Maintenant que vous êtes lancés...

Ce guide a été conçu comme un point de départ pour vos propres aventures d’optimisation de l’e-mail pour mobile. Le monde mobile est en constante évolution, tout comme le sont les techniques visant à un meilleur rendu des e-mails dans un contexte de grande diversité des clients mails. Donc si vous avez une suggestion quant à la façon dont nous pouvons améliorer ce guide, ou des questions à propos des designs réactifs pour e-mail, n’hésitez pas à entrer en contact avec notre équipe. Bonne conception !

Fiche technique

  • Article original : Responsive Email Design : Case study: Twitter
  • Auteur : Campaign Monitor
  • Traduction : Aurélie Rigouste
  • Relecture : Nicolas Contant
  • Date de traduction : octobre 2013
  • Thème : Web Mobile


Pompage.net - CSS : on reprend tout à zéro !

Changez-vous la vie avec XHTML

Par J. David Eisenberg

Le XHTML est un langage de balisage standard pour les documents web, et le successeur du HTML 4. Mélange de classique (HTML) et d'avant-garde (XML), ce langage hybride ressemble au HTML et fonctionne de la même manière, tout en étant basé sur XML, le "super" langage de balisage du web. Il apporte donc aux pages web de nombreux avantages du XML, comme ceux énumérés dans le Guide de Style en Ligne des Filiales de la Bibliothèque Publique de New York.

Si vous voulez que votre site fonctionne correctement dans les navigateurs et les outils non-traditionnels d'aujourd'hui, et qu'il continue à bien fonctionner dans ceux de demain, ça ne serait peut-être pas une mauvaise idée de créer vos nouveaux sites en XHTML, et de convertir les anciens quand votre planning vous le permet.

Et comme de plus le W3C vous facilite la tâche, vous pouvez apprendre les règles du XHTML en moins de temps qu'il n'en faut à Pizza Hut pour livrer une 4 saisons. Ces quelques règles simples illustrent l'aspect pratique des règles du W3C, car elles apportent une cohérence et une syntaxe XML correcte au web sans obliger designers et développeurs surchargés à apprendre entièrement de nouvelles méthodes de balisage.

Toutefois comme pour toute transition, vous obtiendrez les meilleurs résultats et les plus prévisibles avec un peu de préparation. Cet article va vous y aider, en examinant les outils qui peuvent vous aider à convertir vos pages en XHTML et à vérifier que vous l'avez fait correctement. Il traitera aussi des différences dans la manière dont certains navigateurs affichent les pages XHTML, différences qui pourraient vous étonner si vous ne vous y attendez pas, ainsi que des méthodes utilisées pour les contourner si besoin.

Un homme averti en vaut deux

Si vous ne l'avez pas déjà fait, lisez le Guide de Style en Ligne des Filiales de la Bibliothèque Publique de New York avant de continuer cet article.

Ce Guide de Style fait la lumière sur le XHTML sans vous obliger à fouiller dans la littérature souvent hermétique du W3C. Il inclut des informations utiles sur les CSS (y compris des feuilles de style que vous pouvez récupérer et utiliser sur vos propres sites). Il explique comment travailler avec les validateurs du W3C, et offre des astuces pour les utilisateurs de Dreamweaver.

L'auteur de ces lignes a aidé la Bibliothèque Publique de New York à créer le guide, et il est reconnaissant à la Bibliothèque et à son coordinateur web (et co-créateur du Guide de Style) Carrie Bickner d'avoir choisi de mettre ce guide à la disposition de la communauté. Le Guide de Style est fréquemment mis à jour pour corriger des erreurs et fournir de nouvelles informations.

Tidy

La méthode la plus facile pour créer des pages XHTML valides est encore de les coder en partant de zéro. Mais l'essentiel du design web est en fait du redesign web, et vous aurez souvent à mettre à jour d'anciennes pages. Ce qui constitue la meilleure opportunité pour migrer vers le XHTML.

HTML Tidy est un outil gratuit qui peut convertir votre HTML en XHTML. Nous l'avons récemment utilisé à cet effet sur le Daily Report de zeldman.com. Nous avons également utilisé Tidy pour la conversion du site A List Apart en CSS/XHTML l'année dernière, et nous l'avons employé avec succès sur plusieurs sites de nos clients.

Tidy, créé par le brillant Dave Ragett, est aujourd'hui maintenu en Open-Source par la communauté web sur le site Source Forge, même si certaines versions sont maintenues par les initiatives individuelles de véritables amoureux de ce logiciel.

Pour notre conversion, nous avons utilisé MacTidy 1.0b13, la version de Tidy la plus récente pour Mac OS, développée par Terry Teague (le site de Terry pourrait être temporairement inaccessible quand vous suivrez ce lien, son hébergeur lui permettant de transférer seulement une quantité de données limitée toutes les heures. Si vous rencontrez des problèmes, réessayez plus tard.)

Il existe des versions en ligne de Tidy, comme des versions téléchargeables pour Windows, UNIX, différentes distributions de LINUX, Mac OS, et différentes plateformes, chacune d'entre elles possèdant des capacités différentes et donc sa propre documentation.

Lisez le manuel

Comme beaucoup de personnes occupées, nous avons tendance à éviter de lire les manuels, mais dans le cas de Tidy nous vous conjurons d'en lire le moindre mot. Même si certaines versions de Tidy semblent rudimentaires et que ses capacités semblent évidentes, Tidy est un outil puissant. Vous devez donc vous familiariser avec ses préférences et ses réglages pour vous assurer du résultat désiré.

Pour notre conversion du Daily Report, nous nous sommes rafraîchi la mémoire avec un bref coup d'oeil à la documentation de MacTidy, et cela s'est avéré être une erreur.

Au premier passage, en utilisant des paramètres que nous n'avions jamais testés auparavant, Tidy a converti nos entités de caractères encodées en caractères non-encodés et spécifiques à la plateforme. Il a tranformé des entités Unicode fonctionnant dans tous les navigateurs en entités nommées qui devraient fonctionner dans tous les navigateurs mais ne le font pas. Enfin il a changé les < des commentaires <!-- en caractères encodés, déclenchant ainsi des erreurs dans une fonction JavaScript.

Le pouvoir était celui de Tidy, la faute était la nôtre. Une utilisation incorrecte de Photoshop, d'Illustrator ou de Flash peut avoir les même conséquences, et Tidy ne pouvait être rendu responsable des erreurs de ses utilisateurs. Alors rendez-vous trois services :

  1. lisez le manuel ;
  2. gardez une copie de sauvegarde de votre document ;
  3. lisez le manuel.

Ceux qui partagent notre problème de rapport au manuel voudront savoir quel était le réglage de préférence correct. Malheureusement, il n'y a pas de réglage "correct". Le réglage varie suivant le type d'encodage de caractères que vous désirez spécifier dans votre header, le type d'encodage que vous avez spécifé dans votre éditeur HTML (habituellement latin1), et d'autres variables. Cependant, si vous voulez générer du XHTML, suivez ce conseil et assurez-vous de choisir la préférence Convert HTML to XML (car rappelez-vous que le XHTML n'est en réalité que du XML).

Se préparer à valider

Le Guide de Style explique comment travailler avec les validateurs (X)HTML et CSS du W3C. La validation prend juste quelques instants. Si vous évitez cette étape et si votre XHTML ou vos CSS contiennent des erreurs, votre site pourrait ne pas fonctionner correctement. Il pourrait aussi s'afficher fort différemment de ce que vous souhaitiez.

Avec un balisage et des CSS valides, les navigateurs conformes aux standards afficheront votre site de la manière attendue, avec des exceptions que nous traiterons plus bas. Avec du XHTML ou des CSS invalides, on rentre dans le domaine de l'imprévisible, et vous ne pourrez en blâmer les navigateurs (bon allez, vous pouvez, mais c'est injuste et ça ne vous avancera à rien).

Si vous écrivez votre code à la main, à moins d'être parfait, il y a des chances pour que vous fassiez des erreurs de temps en temps. Si vous utilisez Macromedia Dreamweaver ou Adobe GoLive avec leurs réglages par défaut, votre site contient sûrement des erreurs que les validateurs peuvent vous aider à corriger.

Nous avons pleine confiance dans le fait que les versions à venir de Dreamweaver ou de GoLive vous aideront à créer du code plus valide, mais ces versions ne sont pas encore sur le marché, et même lorsqu'elles le seront, vous pourrez encore avoir besoin de bricoler votre code à la main (en attendant, les utilisateurs de Dreamweaver devraient consulter les astuces du Guide de Style, mises à jour le 15 février 2002 pour coincider avec le présent article).

Quelle que soit la manière dont vous générez votre code, travailler avec les validateurs s'avère payant. Ils sont comme des consultants XHTML et CSS neutres qui vous montreront vos problèmes sans penser aucun mal de vous.

Problèmes de navigateurs

Même les meilleurs consultants donnent parfois de mauvais conseils. Ils peuvent manger trop d'ail à midi, ou utiliser votre fax plus que vous ne le souhaiteriez. Les consultants robotiques que l'on trouve aux adresses validator.w3.org et jigsaw.w3.org/css-validator peuvent également vous créer des problèmes inattendus.

Principalement, cela est dû au langage que les validateurs utilisent pour rapporter les erreurs. Ecrits par et pour des techniciens des standards, les validateurs offrent parfois une "aide" qui peut confondre ou égarer les utilisateurs moyens. Bien sûr ce n'est pas le travail du W3C de nous pré-mâcher les standards web, mais nous aimerions parfois que les navigateurs nous indiquent, "Hé, idiot, tu as oublié de fermer ta balise <p>" au lieu des commentaires cryptiques qu'ils nous sortent occasionnellement.

Pourquoi ce cryptage, camarade ?

Pour être honnête, les messages cryptiques des validateurs découlent souvent des limitations du logiciel. Le validateur n'est pas HAL dans 2001 l'Odyssée de l'Espace. Si vous oubliez de fermer une balise, le validateur ne peut pas savoir que vous aviez l'intention de la fermer, et peut alors indiquer une erreur plus bas dans la page, au lieu de désigner le problème réel. Le validateur peut pointer vers une balise mal imbriquée qui est, en fait, bien imbriquée -- alors qu'une balise précédente ne l'est pas, ce qui suffit à hébéter le validateur.

En tant que créateur, vous êtes responsable de vos propres erreurs, qu'elles soient générées par un outil (peut-être mal utilisé) ou tapées à la main. Savoir que les validateurs XHTML ont tendance à signaler les erreurs d'imbrication en dessous de l'endroit où elles ont en fait eu lieu peut vous aider à déjouer les pièges des rapports d'erreur et à vous remettre en selle rapidement.

Autres problèmes courants

Beaucoup d'éditeurs HTML courants génèrent des DOCTYPEs avec des URI relatives, du genre...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "DTD/XHTML1-strict.dtd">

Ces URIs génèrent invariablement des erreurs de validation CSS quasiment impossibles à déchiffrer par un simple mortel. Nous nous sommes tapés la tête contre les murs jusqu'au sang à cause de messages du genre de celui-ci :

org.xml.sax.SAXException: Please, fix your system identifier (URI) in the DOCTYPE

La méconnue FAQ du validateur CSS traduit ces balbutiements de savant fou dans un anglais courant, et explique comment corriger les problèmes. Dans l'exemple donné ci-dessus, la solution est d'utiliser un DOCTYPE avec une adresse absolue, comme :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/XHTML1/DTD/XHTML1-transitional.dtd">

Nous partagerons des astuces importantes sur les DOCTYPEs plus tard dans cet article.

Un autre problème courant qui ne dérange pas les validateurs -- mais répand le chaos dans les vieux navigateurs et même dans certains des plus récents comme IE 6 -- concerne le prologue XML optionnel qui précède le DOCTYPE et les déclarations d'espaces de noms. Encore une fois, veuillez vous rapporter au guide XHMTL du NYPL Style Guide pour plus de détails, ainsi que pour la solution.

D'autres problèmes de validation courants (et leurs solutions) sont couverts dans l'article d'Eric Meyer Liberté ! Égalité ! Validité ! paru sur Netscape DevEdge.

Bugs de validateurs

Les validateurs sont également des produits de fabrication humaine, et donc, comme tout logiciel, ils contiennent quelques bugs. Vous devriez signaler ces bugs lorsque vous les rencontrerez (nous vous dirons comment plus loin), mais vous pourriez hésiter à le faire, plus porté à mettre en doute votre propre balisage qu'un puissant ordinateur programmé par des experts des standards. Sachez pourtant, qu'exceptionnellement, il arrive de constater que le validateur comporte aussi des bugs.

Lors de notre précédente rencontre avec Tidy, en utilisant des mauvais réglages, nous avons obtenu une page web qui n'était pas tout à fait correcte, que nous avons décidé de corriger à la main, sans réaliser, que nous avions laissé passé une erreur.

Obéissant à notre réglage approximatif, Tidy a converti nos symboles copyright encodés © en symboles copyright du clavier Macintosh. Ce caractère clavier ne pose pas de problème pour un transfert de fichiers de Macintosh à Macintosh, mais il est à déconseiller sur le web. Nous avons passé la page dans le validateur du W3C et elle s'en est sortie haut la main.

Nous avons ensuite essayé de valider notre feuille de style, mais le validateur CSS du W3C nous a informé qu'il ne pouvait pas le faire à cause d'une erreur dans notre XHTML : “An invalid XML character (Unicode: 0xa9) was found in the element content of the document.”

Situation inextricable

Malheureusement, nous ne pouvions rechercher et remplacer "0xa9" puisque 0xa9 n'est pas une chaîne de charactères existant dans notre document (0xa9 correspond au symbole copyright en Unicode, mais à moins d'avoir la table de ces caractères en tête, le message du validateur ne sert pas à grand chose).

Le validateur CSS nous a fourni les références de ligne et de colonne pour chaque erreur, et celles-ci auraient pu nous être utiles pour repérer le problème si elles se rapportaient à quelque chose. Mais les références restaient muettes puisque le validateur CSS n'affiche pas le balisage.

Le validateur du W3C affiche quant à lui le code complet avec les références de lignes, mais seulement s'il le croit défectueux. Et comme nous l'avons dit, ce validateur considérait notre balisage comme étant tout ce qu'il y a de plus kasher.

Nous nous sommes alors retrouvés dans une situation inextricable avec un validateur qui disait que notre page était correcte tandis que l'autre plantait et nous fournissait des messages d'erreurs inutilisables.

Momentanément déconcertés, nous avons malgré tout mis cette page en ligne, et dans l'heure, les lecteurs du Daily Report, avec entre autres Mark Howells, Zeke Runyon, et Dylan Foley, avaient pris sur eux-même de relire notre code source et de trouver l'erreur. Nous les en avons remerciés, nous avons corrigé notre erreur, et nous sommes repartis de plus belle.

Si nous avions travaillé sur le projet d'un client au lieu d'un site personnel, nous n'aurions pas mis la page en ligne avant d'avoir trouvé et corrigé l'erreur. Dans la plupart des cas, il est bon de fermer votre éditeur HTML, d'aller faire un tour, et de revenir plus tard, avec l'esprit plus clair.

Signaler les bugs de validateurs

De tels problèmes sont assez rares (et dans notre cas, ils auraient pu être évités par la lecture du manuel), mais ils surgissent parfois. Un de nos amis, qui a été appelé "le plus grand web designer vivant" tape pourtant fréquemment des caractères clavier Windows dans son code source. Aussi sachez que les erreurs de balisage peuvent se produire et que les erreurs de validation arrivent elles aussi (assez rarement toutefois).

Si vous pensez que le validateur du W3C est dans l'erreur, visitez la page des feedbacks utilisateurs. Pour rapporter les erreurs possibles du validateur CSS, écrivez à www-validator-css@w3.org (l'adresse email présente sur la page ReadMe du validateur CSS ne fontionne pas car elle est incomplète). Si le validateur est effectivement fautif -- ou si vous avez de fortes présomptions sur le sujet -- soyez sympas et signalez l'erreur.

Les validateurs du W3C sont des ressources gratuites maintenues avec amour par des gens compétents. Se montrer rude dans votre correspondance, même si ça vous tente, soit offensera ces travailleurs acharnés, soit (plus vraisemblablement) leur fera se demander pourquoi vous êtes si frustres et les aménera à transférer immédiatement votre message dans leur corbeille.

XHTML et les navigateurs

Alors vous avez maintenant une page XHTML valide. A-t-elle toujours la même apparence ? Dans quelques navigateurs récents et conformes aux standards, il est possible que non -- mais vous pouvez corriger cela rapidement.

Après avoir converti le Daily Report de HTML 4.01 Transitional à XHTML 1.0 Transitional, notre page était en tout point identique à la page originale, sauf pour le changement de DOCTYPE et des règles de balisage.

Mais IE6 et Mozilla/Netscape 6 ont décidé que la page devait avoir l'air différente. Voici ce que IE6/windows a fait à notre barre de menu :

IE6 détruit la barre de menu.

Et voici les sentiments de Netscape 6.2/Mac sur le sujet :

NN6 détruit la barre de menu.

Boucher les trous

Pour corriger ces "bugs" (à notre avis) sous MSIE6 et Mozilla/Netscape 6, nous avons ajouté deux règles dans une feuille de styles incluse dans le header de la page :

.img {display: block;}
.inline {display: inline;}

La première règle a "réparé" la barre de menu, la seconde a corrigé les problèmes d'affichage causés par la première règle. Là où nous voulions que les images s'affichent inline (NdT : display:inline affiche les éléments sur la même ligne, display:block affiche chaque élément comme un bloc), nous avons ajouté une class="inline" à la balise img. Problème résolu.

Si le balisage (la structure) et l'affichage (le design) sont deux animaux différents dans les esprits du W3C, pourquoi ces navigateurs changent-ils notre affichage, et comment en sommes-nous arrivés à corriger ce problème avec deux déclarations CSS ?

Interprétation stricte et bizarreries aléatoires

Comme noté dans le Daily Report (26 janvier 2002), les experts ne sont pas d'accord sur la manière dont un standard comme les CSS devrait être interprété. En particulier, ils ne sont pas d'accord sur les styles qui devraient s'appliquer par défaut aux images n'ayant pas été stylées par le designer.

L'article Tables, Images, and Mysterious Gaps d'Eric Meyer, explique comment les experts CSS du projet Mozilla interprètent les balises images non stylées, en relation avec la grille sous-jacente de chaque page, et fournit des astuces pour ceux qui ne veulent pas d'espaces supplémentaires dans leurs pages web. Ce problème touche surtout les mises en page "combinées", qui utilisent un mélange d'ancien (tableaux) et de nouveau (CSS).

Strict vs. Strict

L'article d'Eric Meyer stipule que Mozilla et son héritier Netscape 6 n'ajoutent des espaces qu'aux documents (X)HTML ayant un DOCTYPE strict, mais cela peut porter à confusion, car il semble suggérer que les espaces supplémentaires apparaissent seulement sur les images d'une page HTML Strict ou XHTML Strict. Un coup d'oeil à plusieurs mailing-lists sur le web design vous montrera que c'est l'interprétation populaire du mot "strict" dans ce contexte.

En fait, ce que Meyer et ses collègues veulent dire par "strict DOCTYPE" est simplement qu'on a affaire à un DOCTYPE complet ou bien valide, c'est à dire à n'importe quel document -- y compris HTML 4.01 Transitional -- incluant une URI complète (Meyer n'utilise pas le terme strict à contre-emploi, c'est juste que le même mot possède différents sens suivant le contexte).

En pratique, nous avons découvert que Netscape 6.x applique son interprétation stricte (celle des experts des CSS) à certains documents HTML 4.01 transitional avec un DOCTYPE complet, et pas à d'autres. Cela vient peut-être du fait que Mozilla est toujours en version Beta, et donc que Netscape 6.x n'est pas achevé. A moins que cela ne recouvre un principe sous-jacent que nous n'avons pas encore réussi à discerner.

Pour revenir à ce qui nous concerne, Mozilla/NN6 applique toujours cette interprétation des CSS -- et donc ces espaces supplémentaires -- aux pages XHTML (Strict ou Transitional). De sorte que lorsque vous convertirez vos pages en XHTML, les images contenues dans les cellules d'un tableau feront à votre mise en page ce que l'Allemagne fit naguère à la Pologne.

DOCTYPEs et affichage

La plupart des navigateurs reconnaissant correctement les CSS utilisent la présence ou l'absence de DOCTYPE complet pour passer en mode "standard-compliant" (NdT: conforme aux standards) ou en mode "backward-compatible" aussi appelé "quirk mode" (NdT: mode "traditionnel" non conforme aux standards), une pratique suggérée en premier (pour autant que l'on sache) par Todd Fahrner en 1998, et implémentée pour la première fois par IE5/Mac en Mars 2000.

Mozilla/NN6 suit cette voie, comme IE6/Win. IE6 inclut également une propriété DOM qui indique si le mode "standard-compliant" est déclenché pour un document donné.

Lorsqu'il se trouve en mode "standards", un navigateur assume que vous savez ce que vous faites, et affiche votre page en suivant les spécifications du W3C. En mode "Quirks", le navigateur considère que vous avez créé une page "à l'ancienne", probablement invalide, et l'affiche comme un vieux navigateur le ferait. Vous contrôlez la voie utilisée par votre navigateur en incluant ou en excluant un DOCTYPE (X)HTML complet.

Référez-vous à Fixing Your Site With the Right DOCTYPE pour savoir quel DOCTYPE vous devriez utiliser pour votre projet web.

(Il y a une exception à cette règle: Mozilla/NN6, comme MSIE, traite les pages HTML 4.0 -- même celles avec un DOCTYPE valide -- en mode "Quirks". Si vous n'êtes pas encore prêt pour le XHTML, mais que vous écrivez du HTML et des CSS valides et que vous voulez que votre page s'affiche correctement, choisissez donc un DOCTYPE HTML 4.01. Sachant bien sûr, que nous vous encourageons à utiliser plutôt du XHTML.)

Après vous être converti au XHTML, si vos images commencent à envahir les frontières de pays voisins, il vous faudra prendre quelques minutes pour ajouter des règles compensatoires à vos feuilles de style. Chaque mise en page est différente, et donc aucune règle ou collection de règles CSS ne corrigeront tous vos problèmes, mais l'article d'Eric Meyer et les règles que nous avons listé ci-dessus devraient vous procurer un bon point de départ, et ce travail supplémentaire ne devrait pas vous prendre trop longtemps.

Espaces blancs et affichage

A travers l'article d'Eric Meyer, Mozilla/Netscape a documenté la manière dont il fonctionne. Nous ne sommes pas sûrs de la raison pour laquelle IE6/Win a décidé de modifier l'affichage lorsque nous avons passé le DOCTYPE de notre page en XHTML (Les deux versions -- la vieille HTML 4.01 Transitional et la nouvelle XHTML 1.0 Transitional -- utilisent des DOCTYPEs complets).

Nous pensons que cela est lié à la manière dont les navigateurs gèrent les espaces blancs (dans le code source -NdT). Chacune des deux balises ci-dessous est équivalente d'un point de vue fonctionnel, mais à cause de leur usage (ou non-usage) des espaces blancs, elles peuvent s'afficher différemment dans des navigateurs qui essayent d'analyser les espaces blancs dans le balisage, de sorte que :

<td><img src="foo.gif" /></td>

... pourrait s'afficher différemment de :

<td>

  <img src="foo.gif" />
</td>

Le second exemple -- celui avec des espaces blancs dans le balisage -- pourrait produire des trous visuels indésirables dans votre mise en page. De la même manière, dans l'exemple suivant, la première balise (celle sans espace blanc) ...

<td><a href="/traduction/mieuxvivre#foo"><img src="foo.gif" /></a></td>

... pourrait s'afficher différemment du balisage suivant, pourtant fonctionnellement identique :

<td>
  <a href="/traduction/mieuxvivre#foo">
  <img src="foo.gif" />
  </a>
</td>

Quelle est la raison de ce comportement ? Le "bug de l'espace blanc" était un problème connu dans Netscape Navigator depuis sa version 3.0 (au moins). Quand Microsoft a décidé de construire un navigateur concurrent, ses ingénieurs ont émulé la plupart de comportements de Netscape -- y compris quelques-uns de ses bugs. Nous croyons que MSIE6 continue aujourd'hui à émuler ce vieux bug de Netscape.

Nonobstant la raison d'un tel comportement d'IE6, notre règle additionelle (display: block) a également corrigé le problème dans ce navigateur. Ce truc vous sera plus ou moins utile, mais des variations de (display: block) devraient corriger vos problèmes d'affichage d'images à la fois sous Mozilla/NN6 et IE6.

Le XHTML changera votre vie

Utilisés correctement, les standards du W3C améliorent l'accessiblité et promettent une durabilité à long terme (que nous appelons "compatibilité ascendante") à tout document publié sur le web. S'il est important pour vous d'avoir accès au public le plus large pour une durée la plus longue possible, les standards web sont le choix qu'il vous faut, et là où la structure des documents est concernée, le XHTML est le chemin à suivre.

Alors que les standards du W3C sont créés pour aider les experts à accomplir des tâches sophistiquées, le balisage (XHTML) et les feuilles de style sont faits pour tous, et le W3C a pris la peine de paver la voie qui y conduit.

Les règles du XHTML prennent quelques minutes à apprendre et ses bénéfices sont immenses. Il est facile de créer des pages en XHTML et tout aussi facile de convertir du HTML en XHTML à la main. Des outils comme Tidy peuvent aider à automatiser le processus, du moment que vous prenez quelques minutes pour lire la documentation avant d'appuyer sur le bouton.

Les validateurs en ligne gratuits vous aideront à vous assurer que votre XHTML et vos CSS sont corrects, même si les rapports d'erreur peuvent parfois vous dérouter, et si dans de très rares circonstances le validateur peut se planter.

Après être passé au XHTML, vous pourriez avoir à ajuster votre feuille de style de manière à compenser les défauts de présentation d'images de certains navigateurs, particulièrement à l'intérieur des tableaux. Mais si vous intégrez ces étapes à votre méthode de travail, cela deviendra vite une seconde nature. Et, les nouveaux navigateurs gagnant des parts de marché, nous travaillerons de moins en moins avec des tableaux, et de plus en plus avec des CSS.

Avec un peu d'attention et d'amour, le XHTML aidera vos sites à mieux fonctionner avec un plus grand nombre de navigateurs et d'autres appareils, touchant de plus en plus de lecteurs, maintenant et pour les années à venir. Que pourriez vous demander de plus ?

Translated with the permission of A List Apart and the author[s].

Fiche technique

  • Article original : Better Living Through XHTML
  • Auteur : J. David Eisenberg
  • Date de parution : 15 février 2002
  • Traduction : Benjamin Debouté
  • Date de traduction : juin 2003
  • Thème : Web design
  • Niveau : Tous niveaux